2006/11/30, Ian Hickson:
On Thu, 30 Nov 2006, Thomas Broyer wrote:
I'd prefer basing autodiscovery on the media types and not at all on the
relationships. A feed relationship would only help finding the living
resource (similar to rel=current in the Atom Relationship Registry)
if you're not
Andrew Fedoniouk wrote:
|
| p.myclass.../p is equivalent of
| p class=myclass.../p
|
|
| HTML5 is meant to be backwards compatible, so this is out of the question.
And where do you see problems with backward compatibility?
Or let's put this way: what would be a definition of backward
On Dec 1, 2006, at 04:15, Michel Fortin wrote:
that their valid XHTML1 documents served as text/html, when updated
to XHTML5, are now called valid HTML5 documents by the validator.
Except:
* xmlns is illegal in HTML5.
* xml:lang vs. lang.
* base vs. xml:base.
* meta http-equiv... vs.
On Fri, 2006-12-01 at 00:15 -0800, Andrew Fedoniouk wrote:
Probably solution could be in creation of Open HTML/CSS/Script
specification that will make conditions for competition of various
approaches/technologies. Who knows?
I doubt it. HTML persists as a mainstream format because Internet
On 11/30/06, Ian Hickson [EMAIL PROTECTED] wrote:
I'd gladly put in a !DOCTYPE html in my page, the question is: would
the WHATWG be willing to meet me half way and allow xmlns attributes in
a very select and carefully prescribed set of locations?
This seems like a bad idea. If you have
Hi,
It is obvious, but should still be specified that start tags with attributes
can't be omitted.
Regards,
Simon Pieters
_
Leta bloggar om dina intressen
http://spaces.live.com/default.aspx?page=Interestsss=False
2006/12/1, Ian Hickson [EMAIL PROTECTED]:
...
An example of something that is NOT implemented interoperably is
script src=.../.
As far as I can tell, script/ is handled by all browsers the same way as
script. How is it not interoperable?
That's true, however, what happens depends on the
Hi,
This sentence:
However, a start tag must never be omitted if the element
to which it belongs is immediately preceeded by another
element with the same name, whose end tag has been omitted.
AFAICT, this only applies to colgroup. Why not move this requirement to
the colgroup entry?
The spec tells us:
The lang attribute only applies to HTML documents. Authors must not
use the lang attribute in XML documents. Authors must instead use
the xml:lang attribute, defined in XML. [XML]
To determine the language of a node, user agents must look at the
nearest ancestor
The contents of the element must be placed between just after the start
tag (which might be implied, in certain cases) and just before the end
tag (which again, might be implied in certain cases).
I wonder about the just after and just before. Is there something in
the middle that is not just
The XML 1.0 and most related specifications use the hyphenated spellings
start-tag and end-tag. The Web Apps 1.0 spec uses the unhyphenated
forms start tag and end tag.
While I'm not sure there's a fundamental reason to prefer one form over
the other, the copy editor in me would prefer to be
9.1.2.1 states:
Then, if the element is one of the void elements, then there may be a
single U+002F SOLIDUS character. This character has no effect except to
appease the markup gods. As this character is therefore just a symbol of
faith, atheists should omit it.
The second sentence is
Hi,
Since there are some dfns in headings, the table of contents now also
contains dfns, resulting in duplicate defined terms. Since the spec
doesn't allow duplicate defined terms, I guess this was not intentional...
Regards,
Simon Pieters
Elliotte Harold wrote:
This character has no effect when the document is parsed by an HTML5
parser. However, if the document when parsed by an XML parser, the
trailing slash converts the tag into an empty-element tag, and thereby
makes an otherwise malformed element well-formed.
If you're
On Fri, 01 Dec 2006 13:16:28 +0100, Elliotte Harold
[EMAIL PROTECTED] wrote:
Attributes names and unquoted attribute values must be separated from
each other and from the tag name and the U+002F SOLIDUS character
mentioned below (if present) by one or more space characters.
Is this then
The Unicode spec spells code point as two words; the Web apps 1.0 spec
uses one: codepoint. I suggest we follow the Unicode spelling.
--
Elliotte Rusty Harold [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
Hi,
The dfn element:
The dfn element represents the defining instance of a term.
The paragraph, definition list group, or section that contains
the dfn element contains the definition for the term given
by the contents of the dfn element.
Given the definition of defining term two
In 9.1.3 we see
Text must consist of valid Unicode characters other than U+. Text
should not contain control characters other than space characters.
Later in 9.2.3.1 we find:
If the number is not a valid Unicode character (e.g. if the number is
higher than 1114111), or if the number is
I wrote:
However, I would vehemently stress that it is not that uncommon
for notes and marginalia to themselves have notes or marginalia,
Then Michael(tm) Smith asked:
I don't doubt that there are some, but are you aware of any
specific examples?
Well, most famously (and if you really want
Michel Fortin wrote:
The spec tells us:
If both the xml:lang attribute and the lang attribute are set, user
agents must use the xml:lang attribute, and the lang attribute must be
ignored for the purposes of determining the element's language.
While the requirement for authors is pretty clear
Le 1 déc. 2006 à 3:47, Henri Sivonen a écrit :
On Dec 1, 2006, at 04:15, Michel Fortin wrote:
that their valid XHTML1 documents served as text/html, when
updated to XHTML5, are now called valid HTML5 documents by the
validator.
Except:
* xmlns is illegal in HTML5.
* xml:lang vs. lang.
Le 1 déc. 2006 à 8:33, Lachlan Hunt a écrit :
If both the xml:lang attribute and the lang attribute are set,
user agents must use the xml:lang attribute, and the lang
attribute must be ignored for the purposes of determining the
element's language.
While the requirement for authors is
On Fri, 1 Dec 2006, Rimantas Liubertas wrote:
As far as I can tell, script/ is handled by all browsers the same
way as script. How is it not interoperable?
That's true, however, what happens depends on the browser and presence
of /script in the code.
Right, the interoperability
On Dec 1, 2006, at 14:38, Elliotte Harold wrote:
1. Are private use characters allowed?
I think the answer should be Yes, because not allowing them could
make people subvert Unicode and use e.g. Latin-1 code points for a
different purpose with a bogus font. Also, not allowing them would
On Fri, 1 Dec 2006, Thomas Broyer wrote:
A summary of my problem with HTML5's autodiscovery:
- there shouldn't be a 'rel' value for subscribability,
subscribability is a matter of whether and how an UA can process
content from a particular media type
Agreed. The spec doesn't mention
On Fri, 1 Dec 2006, Simon Pieters wrote:
It is obvious, but should still be specified that start tags with
attributes can't be omitted.
Good point! Fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \
On Fri, 1 Dec 2006, Simon Pieters wrote:
This sentence:
However, a start tag must never be omitted if the element
to which it belongs is immediately preceeded by another
element with the same name, whose end tag has been omitted.
AFAICT, this only applies to colgroup. Why not move
On Fri, 1 Dec 2006, Elliotte Harold wrote:
9.1.2.1 states:
Then, if the element is one of the void elements, then there may be a single
U+002F SOLIDUS character. This character has no effect [...]
The second sentence is false [...] I suggest rewriting as follows:
This character has no
On Fri, 1 Dec 2006, Simon Pieters wrote:
Since there are some dfns in headings, the table of contents now also
contains dfns, resulting in duplicate defined terms. Since the spec
doesn't allow duplicate defined terms, I guess this was not
intentional...
Yeah, this is something that will
On Fri, 1 Dec 2006, Elliotte Harold wrote:
Attributes names and unquoted attribute values must be separated from
each other and from the tag name and the U+002F SOLIDUS character
mentioned below (if present) by one or more space characters.
Is this then legal?
p id=p1class=foo
Yes.
On Fri, 1 Dec 2006, Elliotte Harold wrote:
The Unicode spec spells code point as two words; the Web apps 1.0 spec
uses one: codepoint. I suggest we follow the Unicode spelling.
Fair enough. Changed. Please let me know if I let any codepoints slip
back in (which is very likely).
--
Ian
On Thu, 30 Nov 2006, Boris Zbarsky wrote:
No, because an HTML4 UA will not render that in any sort of reasonable
way (for example, in an HTML4 UA the p.myclass tag will never be
closed).
This exactly summarises why we can't do this.
On Thu, 30 Nov 2006, Andrew Fedoniouk wrote:
Boris,
On Fri, 1 Dec 2006, Charles Iliya Krempeaux wrote:
I thought XHTML-sent-as-text/html had explained in painful detail why
that's not a desirable end goal. Why would we want this?
Do you have some links to that discussion. I think I may have missed
it.
(I know I probably don't
On 12/1/06, Kyle Marvin [EMAIL PROTECTED] wrote:
I'm still listening to the debate, but Mark's argument resonates with me.
Yes, Mark is starting to convince me as well.
--
Robert Sayre
Hello Ian,
On 12/1/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 1 Dec 2006, Elliotte Harold wrote:
9.1.2.1 states:
Then, if the element is one of the void elements, then there may be a
single
U+002F SOLIDUS character. This character has no effect [...]
The second sentence is false
On 12/1/06, James M Snell [EMAIL PROTECTED] wrote:
What is the purpose of using alternate links? What is a UA supposed to
do with 'em? Why did I as a content publisher choose to use the
alternate link relation? Are all of these links of equal value to all
UA's? Are they all expected to be
On Dec 1, 2006, at 10:42 AM, Kyle Marvin wrote:
I see the separation but I'm still missing a clear justifiication
for it. I don't see content-type as having anything to do with the
audience. It's about what media format you'd get back if you
dereference the href and rel is about how you
You're right that the differentiation in the content-type is of less
importance but without it there's no way for me to unambiguously
indicate that a resource has both an Atom Feed representation and an
Atom Entry representation. The best I could do is say This things has
two Atom
On Fri, 1 Dec 2006, Sam Ruby wrote:
Except that wouldn't be backwards compatible since xml:lang= isn't
treated as a language attribute in legacy UAs.
I thought that the HTML definition of backwards compatibility was If a
user agent encounters an attribute it does not recognize, it
On Fri, 1 Dec 2006, Simon Pieters wrote:
If an attribute using the empty attribute syntax is to be
followed by another attribute or by one of the optional U+002F
SOLIDUS (/) characters allowed in step 6 of the start tag
syntax above, then there must be a space character separating
On Fri, 1 Dec 2006, James M Snell wrote:
You're right that the differentiation in the content-type is of less
importance but without it there's no way for me to unambiguously
indicate that a resource has both an Atom Feed representation and an
Atom Entry representation.
Assuming that an
Hi,
From: Ian Hickson [EMAIL PROTECTED]
If an attribute using the empty attribute syntax is to be
followed by another attribute or by one of the optional U+002F
SOLIDUS (/) characters allowed in step 6 of the start tag
syntax above, then there must be a space character separating
Simon Pieters wrote:
Hi,
The dfn element:
The dfn element represents the defining instance of a term.
The paragraph, definition list group, or section that contains
the dfn element contains the definition for the term given
by the contents of the dfn element.
Given the definition of
I could but after the discussions this week I'm not sure its worth it.
Yes, everything can be done using different rel values; the content-type
thing is more just an annoyance than anything else. I'll just make sure
that I never link my Atom entry documents using alternate (even tho
that's what
Lachlan Hunt wrote:
Mike Schinkel wrote:
1.) I read the FAQ http://blog.whatwg.org/faq/ and it seemed to imply
that HTML 5 and XHTML where not at odds with each other? Did I
misread that, because from comments on this thread I get the
impression that might not be the case.
2.) A
Ian Hickson wrote:
On Thu, 30 Nov 2006, Mike Schinkel wrote:
1.) I read the FAQ http://blog.whatwg.org/faq/ and it seemed to imply
that HTML 5 and XHTML where not at odds with each other? Did I misread
that, because from comments on this thread I get the impression that
might not be
Le 1 déc. 2006 à 11:44, Ian Hickson a écrit :
On Fri, 1 Dec 2006, Michel Fortin wrote:
Okay, so if I understand well, xml:lang in the spec refers to the
lang
attribute in the xml namespace, not to the xml:lang attribute
in the
null namespace that you get with the HTML parser. It makes
On Fri, 1 Dec 2006, Mike Schinkel wrote:
Even though they are both serializations, the vast majority of people
producing HTML/XHTML are not doing it by serializing, they are doing it
by string concatonation and merging templates. Unfortunately, no matter
how much it's lamented that this
Le 1 déc. 2006 à 11:07, Ian Hickson a écrit :
On Fri, 1 Dec 2006, Michel Fortin 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
On Fri, 1 Dec 2006, Michel Fortin wrote:
Yes I see. At the time I thought the spec required xml:lang to work in
HTML, because of the way xml:lang is mentioned in the section about the
lang attribute. Now I see it's the lang attribute in the xml
namespace that would work, not the xml:lang
On Sat, 2 Dec 2006, Thomas Broyer wrote:
2006/12/1, Ian Hickson:
On Fri, 1 Dec 2006, Thomas Broyer wrote:
A summary of my problem with HTML5's autodiscovery: - there
shouldn't be a 'rel' value for subscribability, subscribability is
a matter of whether and how an UA can process
2006/12/1, Mark Baker:
Urgh, sorry for my tardiness; I'm falling behind on my reading.
On 11/30/06, Thomas Broyer wrote:
I'd prefer basing autodiscovery on the media types and not at all on
the relationships.
All a media type tells you (non-authoritatively too) is the spec you
need to
On 12/1/06, Ian Hickson [EMAIL PROTECTED] wrote:
What do you think?
I don't think it's a goal for the two serialisations to have a common
subset.
I want to cut and paste MathML and SVG and other things into my web
pages. I think I understand the difference between the XML and HTML5
On Dec 2, 2006, at 01:14, Ian Hickson wrote:
To convert an Appendix-C-compliant document to HTML5, one would
just need to change the DOCTYPE and drop the namespace declaration
and one
would be pretty close (there might be some other esoteric things to
change, but probably not many).
On Fri, 1 Dec 2006, Robert Sayre wrote:
I want to cut and paste MathML and SVG and other things into my web
pages.
Then you'll have to use the XML variant and the XML MIME type.
(Similarly, if you want to use JavaScript code snippets, you have to use
JavaScript and can't use, say, C++ or
On 12/1/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 1 Dec 2006, Robert Sayre wrote:
I want to cut and paste MathML and SVG and other things into my web
pages.
Then you'll have to use the XML variant and the XML MIME type.
Why? I don't care if features that rely on XML serialization
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 bad idea, but allowing them is not a problem for HTML5
On Fri, 1 Dec 2006, Robert Sayre wrote:
On 12/1/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 1 Dec 2006, Robert Sayre wrote:
I want to cut and paste MathML and SVG and other things into my web
pages.
Then you'll have to use the XML variant and the XML MIME type.
Why?
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.
...
This is why the spec is defined in terms of the DOM,
59 matches
Mail list logo
