Bill de hÓra wrote:
Thomas Broyer wrote:
* it is not less reliably implementable than the current draft's
mandatory div element; if we go for a SHOULD or MAY on discarding
the div elements, it is even *more* reliably implementable.
We had a discussion about optional div not so long ago,
Thomas Broyer wrote:
Bill de hÓra wrote:
Thomas Broyer wrote:
* it is not less reliably implementable than the current draft's
mandatory div element; if we go for a SHOULD or MAY on discarding
the div elements, it is even *more* reliably implementable.
We had a discussion about optional
On May 23, 2005, at 12:31, Julian Reschke wrote:
For the record: I am +1 on
http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv.
+1 from me too.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
On 24 May 2005, at 9:40 am, Henri Sivonen wrote:
On May 23, 2005, at 12:31, Julian Reschke wrote:
For the record: I am +1 on http://www.intertwingly.net/wiki/pie/
PaceOptionalXhtmlDiv.
-1, and additionally I don't think the Pace is even complete or
reliably implementable.
Graham
On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren
[EMAIL PROTECTED] wrote:
* 4.2.2 The atom:category Element
Why is significant information hidden in attributes? That is bad
for i18n and prevents people from defining the expansion of an
abbreviation, for example.
Minor flaw. It
Graham wrote:
On 24 May 2005, at 9:40 am, Henri Sivonen wrote:
On May 23, 2005, at 12:31, Julian Reschke wrote:
For the record: I am +1 on http://www.intertwingly.net/wiki/pie/
PaceOptionalXhtmlDiv.
-1, and additionally I don't think the Pace is even complete or
reliably implementable.
Asbjørn Ulsberg wrote:
On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote:
* 4.2.2 The atom:category Element
Why is significant information hidden in attributes? That is bad for
i18n and prevents people from defining the expansion of an
abbreviation, for example.
Minor flaw. It
Thomas Broyer wrote:
Graham wrote:
-1, and additionally I don't think the Pace is even complete or
reliably implementable.
FYI, it is not,
Oops, before it'd be misinterpreted:
* the Pace is not *complete*
* it is not less reliably implementable than the current draft's mandatory
div
Thomas Broyer wrote:
* it is not less reliably implementable than the current draft's mandatory
div element; if we go for a SHOULD or MAY on discarding the div elements,
it is even *more* reliably implementable.
We had a discussion about optional div not so long ago, and I came away
Robert Sayre wrote:
What happens when it does contain child elements? I think we should
define that for interoperability. (See HTML for what happens when
you don't.) This question also applies to the next section.
No, that's broken. There can be no expectation of interoperability.
I think
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 09:05]:
Robert Sayre wrote:
For white-space significance text I need to use 'html' or
'xhtml' instead using PRE or xhtml:pre?
I don't understand what you're saying here, but I'm pretty
sure every possible whitespace issue has been debated
A. Pagaltzis wrote:
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of
XHTML? (I really dislike this combined construct by the way.)
I used to find it extremely horrible. Now I’m not sure.
* Thomas Broyer [EMAIL PROTECTED] [2005-05-23 10:50]:
A. Pagaltzis wrote:
There is some symmetry here: with @type=xml, you have to
Which @type=xml? Did you mean @type=text/xml?
Sorry, I meant any XML media type.
enclose a full XML document, which will always have a root
element. The
Thomas Broyer wrote:
It is not, not at all.
To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or
-1, but at least argument. See also further explanation and technical
arguments in Consensus call on last raft of issues [1]
...
For the record: I am +1 on
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 10:35]:
A. Pagaltzis wrote:
Last I asked, I understood that whitespace would be preserved
if you supply 'text/plain' content; @type='text' is more like
inline text in an XML document (or in HTML). Maybe the spec
could be more explicit about
On 5/23/05, Anne van Kesteren [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
What happens when it does contain child elements? I think we should
define that for interoperability. (See HTML for what happens when
you don't.) This question also applies to the next section.
No, that's
Sunday, May 22, 2005, 10:22:24 AM, you wrote:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of XHTML? (I
really dislike this combined construct by the way.)
You can, but you would have to embed a full XHTML document, including
html and body elements.
On May 22, 2005, at 11:47 AM, Robert Sayre wrote:
# Any element defined by this specification MAY have an xml:lang
# attribute, whose content indicates the natural language for the
# element and its children.
s/children/descendents/?
Someone speak up if there's a preference out there
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of
XHTML? (I really dislike this combined construct by the way.)
I used to find it extremely horrible. Now Im not sure.
There is some symmetry
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 3.1.1.3 XHTML
I would like to see valid XHTML more clearly defined. There
are a lot of different XHTML versions I know of and some might
not include a DIV element at all... You have XHTML 1 (in three
versions), XHTML 1.1, XHTML
20 matches
Mail list logo
