Re: [whatwg] element comments

[Lachlan Hunt]

Matthew Raymond wrote:

Lachlan Hunt wrote:
I disagree.  Specifying the size is very good for incremental rendering, 
but the alternatives are awful.


1. 

The style attribute is far more presentational than the height and width 
attributes.


   I don't see how either is more or less presentational. The |height|
and |width| attributes are entirely presentational, since their sole
purpose is to define the sizing of the image in the document layout.


Using attributes to describe actual metadata about an image that has 
real practical benefits, for both the author and user, is not 
presentational in my view.


There's even an edge case where specifying incorrect dimensions could 
still be considered semantic.  Unfortunately, I can't find the site I'm 
thinking of, but I've seen a site somewhere that created art by using 
small images and stretching them for the pixelation effect.  In this 
case, stretching the image is part of the artwork's artistic value and 
meaning, not just it's presentation, and it would lose it all if the 
image were shown at it's actual size.



They do not give the dimensions of the image itself,


That all depends on the values the author gives them.  Unfortunately, 
the exact behaviour of how to handle incorrect dimensions was not 
specified and so browsers implemented it the way they did by stretching 
the image to fit, instead of any of the other alternatives.



2. 

#foo { height: 100px; width: 100px; }


   This is not entirely true:

| 

| img[src="foo"] { height: 100px; width: 100px; }


There are dozens of other selectors one could write, but my point was 
that writing such a thing for each individual image is far too much 
effort.  It's a completely unnecessary level of abstraction.


   However, even if this weren't the case, and you has to use |id|, if 
we're talking about images that have non-presentational value and their 
own unique dimensions, aren't we also talking about content that we 
might want to link to directly rather than simply linking to the 
containing page?


I don't understand the point your trying to make.  How is the 
possibility of linking to the image by itself, rather than within a 
page, relevant?


This is simply not feasible in most cases, unless there are very few 
images on the site.  Think about flickr, it just wouldn't be possible to 
specify the dimensions of all their images in a stylesheet.


   You can specify the sizes in an additional 

Re: [whatwg] Footnotes, endnotes, sidenotes

[Matthew Paul Thomas]

On Oct 31, 2006, at 7:57 AM, Alexey Feldgendler wrote:


On Tue, 31 Oct 2006 21:54:12 +0600, David Walbert 
<[EMAIL PROTECTED]> wrote:

...

I would never want to require that a footnote be read to anyone,
thereby interrupting the text -- it is in the nature of a footnote to
be optional reading and to stand apart from the text. Any user should
have the option of reading/hearing it, or not.


But how would the user know that there is a footnote anchored to a 
specific place?

...


By a variation on the way the screenreader tells them there is a link 
anchored to a specific place. For example, an unobtrusive sound effect 
at each footnote reference, and a command to read the last-encountered 
footnote.


--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] [HTML5] Editorial: 3.10.18. The |sup| and |sub| elements

[Matthew Paul Thomas]

On Nov 1, 2006, at 1:32 PM, Christoph Päper wrote:


The second to last example should probably better read:

  E = m · c2

or maybe, as the speed of light is a constant,

  E = m · c2.
...


Is that equation ever legitimately rendered (in physics textbooks etc) 
with the "m" in a different style from the "c"? If not, perhaps the 
definition of  needs to be expanded to include physical constants.


--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] caption (was: How not to fix HTML)

[Matthew Paul Thomas]

On Nov 1, 2006, at 7:50 PM, Michel Fortin wrote:


Le 1 nov. 2006 à 22:01, Jonathan Worent a écrit :
...

or make the association implicit by using the for attribute

A funny video of a man being hit in the groin 
by a football


That would work for the current page layouts of YouTube and Google 
Video.


I think what would work best for this is the  element I've 
proposed back in june:



  Some caption here
  ...

...


That would not. (At least, not without some tricky CSS.)

--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] Footnotes, endnotes, sidenotes

[Matthew Paul Thomas]

On Oct 31, 2006, at 7:20 AM, David Walbert wrote:

...
Footnotes and endnotes are identical in content in the context of a 
print document and I am not certain how they'd differ even 
presentationally on a web page, so yes, I think those can be 
considered identical in terms of markup. 

...


Scholarly books sometimes use both footnotes and endnotes for different 
things -- footnotes for citations and endnotes for tangential 
discussions, or vice versa. I've never seen an HTML document try to 
make this distinction, though.


--
Matthew Paul Thomas
http://mpt.net.nz/

[whatwg] The utility function for semantics in HTML

[Matthew Paul Thomas]

On Nov 1, 2006, at 11:55 AM, James Graham wrote:

...
To take a slight detour into the (hopefully not too) abstract, what do 
people think the fundamental point of semantics in HTML is?


To maximize the utility (usefulness) of documents using it. But this is 
a complicated function.


*   Less presentational -> more medium-independent -> accessible to more
people -> greater utility. (Examples: people using screenreaders or
search engines.)

*   More semantic -> harder to learn and understand -> fewer documents
using it -> less utility. (Example: DocBook.)

*   More semantic -> harder to learn -> simpler alternatives invented
-> learning and/or transcoding-to-HTML effort required -> less
utility. (Examples: Markdown, BBCode, the various
partly-incompatible wiki syntaxes, and any Web comment form that
allows -- or doesn't convey whether it allows -- a subset of HTML.)

*   More semantic -> more machine-analyzable -> greater utility.
(Examples: Google's PageRank with , Google Sets with .)

*   Less presentational -> more semantically-misused -> less
machine-analyzable -> less utility. (Example: XHTML2's attempt to
kill  and , resulting in more misuse of  and .)

Many people concentrate on one or two of these effects and gloss over 
the others, so their idea of the overall utility function is warped.


--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] element comments

[Matthew Raymond]

Lachlan Hunt wrote:
> I disagree.  Specifying the size is very good for incremental rendering, 
> but the alternatives are awful.
> 
> 1. 
> 
> The style attribute is far more presentational than the height and width 
> attributes.

   I don't see how either is more or less presentational. The |height|
and |width| attributes are entirely presentational, since their sole
purpose is to define the sizing of the image in the document layout.
They do not give the dimensions of the image itself, nor could you
define them in such a way without breaking pages. Therefore, the |style|
attribute with width and height properties, however undesirable, is no
worse than using |width| and |height| attributes.

> 2. 
> 
> #foo { height: 100px; width: 100px; }

   This is not entirely true:

| 

| img[src="foo"] { height: 100px; width: 100px; }

   And the above will style all instances of the image, not just the one
with the |id| "foo".

   However, even if this weren't the case, and you has to use |id|, if
we're talking about images that have non-presentational value and their
own unique dimensions, aren't we also talking about content that we
might want to link to directly rather than simply linking to the
containing page?

> This is simply not feasible in most cases, unless there are very few 
> images on the site.  Think about flickr, it just wouldn't be possible to 
> specify the dimensions of all their images in a stylesheet.

   You can specify the sizes in an additional 

Re: [whatwg] The problems with namespaces in text/html

[Henri Sivonen]

On Nov 5, 2006, at 01:19, Elliotte Harold wrote:


Henri Sivonen wrote:

Anne is talking about the text/html serialization, which is  
supposed to be parsed using an HTML5 parser. It is a special- 
purpose alternative serialization for a subset of possible  
infosets--like RELAX NG Compact Syntax. Please ignore the  
superficial syntactic similarity to XML 1.0.


Does that subset include MathML?


Not yet. Whether it should is what is being discussed.

However if the plan is to mix in entire additional languages, then  
I think this is driving off a cliff. MathML and MathML tools are  
designed under the assumption that they can rely on well-formedness  
and namespaces. Integrating MathML with HTML absolutely needs this.


You wouldn't be able to feed MathML-enabled HTML5 to MathML tools  
that use an XML parser. You'd either have to use an HTML5 to XHTML5  
converter for creating an intermediate XML 1.0 serialization that can  
be fed to an XML parser or you could optimize away the serialization  
and plug an HTML5 parser into the XML processing pipeline the way  
TagSoup is used.


It sounds to me like the working group is considering the needs of  
thick-client web browsers


The WHAT WG is very much biased towards Gecko, Presto, WebKit and  
Trident as the consumers of documents.


and people hand-authoring HTML in text editors to the complete  
exclusion of every other community and use case.


Personally, I think MathML is so hopelessly verbose for hand  
authoring that this really shouldn't be about enabling hand authoring  
MathML-in-HTML5 but about enabling MathML-in-HTML5 (perhaps generated  
by a future version of itex2mml or similar) to be served through  
content management systems that are not built around a SAX pipeline  
or an XML tree API or XSLT but are built as tag soup systems and  
simply cannot guarantee well-formedness. I mean systems like  
WordPress and MovableType.


Please prove me wrong. If it's not true that you're planning on  
sending mixed HTML and MathML documents on the wire without  
namespaces or perhaps even well-formedness, then please say so; but  
so far I'm not hearing anyone deny that.


A conforming HTML5 byte stream is *never* a well-formed XML 1.0 byte  
stream. However, for every *conforming* HTML5 byte stream there  
should (in my opinion) exist (in the mathematical sense of existence)  
an XML 1.0 byte stream that parses into the same infoset. (If this is  
not the case, I consider it a spec bug that needs to be fixed.)


So far what has been suggested is that the MathML elements parsed out  
of an HTML5 byte stream would be in the MathML namespace in the infoset.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] Custom elements and attributes

[Øistein E . Andersen]

> I think conforming text/html documents should not be allowed to parse into
> a DOM that contains characters that are not allowed in XML 1.0. [...] I am
> inclined to prefer [...] U+FFFD

I perfectly agree. (Actually, i think that U+7F (delete) and the C1 control 
characters
should be excluded [transformed into U+FFFD] as well, but this could perhaps be
problematic due to spurious CP1252 characters.)

> But of course, there's the issue of what existing browsers do already. :-/

Hopefully, very few pages rely on C0 control characters or the explicitly 
undefined
U+FFFE and U+.

>> I [actually] agree with the intention that names should be restricted to 
>> (mostly)
>> letters and digits [...]
> It's not because I want to restrict names to letters and digits.

Actually, this comment pertained to the intention behind the definition of 
NCName
in XML 1.0, implying that at least the intention was not completely arbitrary.

-- 
Øistein E. Andersen

Re: [whatwg] JSON encoding

[Paul Arzul]

On Sat, 04 Nov 2006 08:06:23 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:


On Fri, 3 Nov 2006, Douglas Crockford wrote:


This is a convenience issue. Having toJSONString as a builtin is a
convenience, removing the need to load json.js.


Assuming the thread is about introducing a way to convert a JS object  
into

a JSON representation, then I would encourage you to contact the
ECMAScript committee. Adding features to JavaScript is out of scope for
the WHATWG specs.


this is getting a bit off topic, but it looks like he already has:

"It is expected that these methods will formally become part of the  
JavaScript Programming Language in the Fourth Edition of the ECMAScript  
standard in 2007."



and it's in the draft spec:


- p

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Lachlan Hunt]

Elliotte Harold wrote:
If all we're doing is HTML, fine. However people are now in this thread 
talking about putting MathML into this.


There has been plenty of discussion about introducing MathML-like markup 
into HTML 5.  Although, personally, I'm not convinced that it's a good 
idea.  This works in Mozilla and, given the right plugins, should work 
in others too.





In other forums people are discussing adding XForms.


I think the discussions about XForms are about trying to retrofit the 
XForms model into the HTML forms syntax.  I'm not convinced that's a 
good idea either, but that's what they've been discussing over on www-forms.


However what I'm hearing is that people do want to mix in different 
vocabularies such as MathML and XForms without using namespaces,


No, not without namespaces, just without the xmlns and QNames syntax.

e.g. when  is encountered in text/html, it appears in the DOM as 
http://www.w3.org/1998/Math/MathML";>


We definitely don't want people thinking they can use any arbitrary 
xmlns in HTML.  That's what XHTML is for.


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] The problems with namespaces in text/html

[Elliotte Harold]

Henri Sivonen wrote:

Anne is talking about the text/html serialization, which is supposed to 
be parsed using an HTML5 parser. It is a special-purpose alternative 
serialization for a subset of possible infosets--like RELAX NG Compact 
Syntax. Please ignore the superficial syntactic similarity to XML 1.0.


Does that subset include MathML?

I can accept a simple, subset designed purely for backwards 
compatibility an that can be processed with a special purpose parser.


However if the plan is to mix in entire additional languages, then I 
think this is driving off a cliff. MathML and MathML tools are designed 
under the assumption that they can rely on well-formedness and 
namespaces. Integrating MathML with HTML absolutely needs this.


It sounds to me like the working group is considering the needs of 
thick-client web browsers and people hand-authoring HTML in text editors 
to the complete exclusion of every other community and use case.


Please prove me wrong. If it's not true that you're planning on sending 
mixed HTML and MathML documents on the wire without namespaces or 
perhaps even well-formedness, then please say so; but so far I'm not 
hearing anyone deny that.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] The problems with namespaces in text/html

[Henri Sivonen]

On Nov 5, 2006, at 00:23, Elliotte Harold wrote:


Anne van Kesteren wrote:
On Sat, 04 Nov 2006 22:56:35 +0100, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:
I've no idea about XForms, but the plan for MathML is that you  
can write it without bothering about namespaces, but that it  
ends up having namespaces in the DOM.


Like hell it doesn't matter! A DOM doesn't travel over the network.  
The serialized form does.


Anne is talking about the text/html serialization, which is supposed  
to be parsed using an HTML5 parser. It is a special-purpose  
alternative serialization for a subset of possible infosets--like  
RELAX NG Compact Syntax. Please ignore the superficial syntactic  
similarity to XML 1.0.


The DOM is one possible local model used to process the document on  
one system. My tools may or may not be based on the DOM, but  
they're going to start by receiving an actual XML instance. We can  
use TagSoup to fudge HTML, but if you I want to handle MathML, SVG,  
and other things in it, That instance had better be namespace well- 
formed, and it had better use the right names for the right things,  
both local and qualified.


He wasn't talking about chameleon namespaces but about the absence of  
namespace *syntax* in the text/html serialization. The HTML5 parser  
is expected to put stuff in the right (non-chameleon) namespaces.


I don't think an HTML5 parser needs to synthetize qualified names.  
Let's just make the equal to local name in APIs that have a hole to  
fill. XML processing is broken anyway if the code is looking at  
qNames rather than the (namespace, local name) pair.


This isn't about chameleon namespaces. (Also I am opposed to  
chameleon namespaces.)


P.S. Since the HTML5 parsing algorithm assumes that it can require  
DOM nodes to be moved or appended higher up in the document, I don't  
expect Tag Soup to ever become a fully conforming HTML5 parser if it  
is to remain SAX streamability instead of buffering everything in a  
tree first. Chances are that users of Tag Soup will appreciate  
streamability more than interop with browsers when it comes to the  
handling of non-conforming documents.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

[whatwg] Space characters

[Henri Sivonen]

Is there a reason why the definition of space characters does not  
match the XML 1.0 and RELAX NG definition of white space (space, tab,  
CR, LF) but also includes (line tabulation and form feed)? Is the  
deviation from XML 1.0 needed for backwards compatibility with text/ 
html UAs?


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] The problems with namespaces in text/html

[Anne van Kesteren]

All good reasons to use XHTML5 and not HTML5. Tools supporting HTML5 will  
have to support the HTML5 parser as well and therefore the HTML5  
serialization. I don't really see your point.



On Sat, 04 Nov 2006 23:23:12 +0100, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:

Yes, exactly the reason they have the correct (MathML) namespace in the  
DOM. So they can be rendered, etc. The serialization format doesn't  
really matter.


Like hell it doesn't matter! A DOM doesn't travel over the network. The  
serialized form does. The DOM is one possible local model used to  
process the document on one system. My tools may or may not be based on  
the DOM, but they're going to start by receiving an actual XML instance.  
We can use TagSoup to fudge HTML, but if you I want to handle MathML,  
SVG, and other things in it, That instance had better be namespace  
well-formed, and it had better use the right names for the right things,  
both local and qualified.



--
Anne van Kesteren

Re: [whatwg] The problems with namespaces in text/html

[Elliotte Harold]

Anne van Kesteren wrote:
On Sat, 04 Nov 2006 22:56:35 +0100, Elliotte Harold 
<[EMAIL PROTECTED]> wrote:
I've no idea about XForms, but the plan for MathML is that you can 
write it without bothering about namespaces, but that it ends up 
having namespaces in the DOM.


Like hell it doesn't matter! A DOM doesn't travel over the network. The 
serialized form does. The DOM is one possible local model used to 
process the document on one system. My tools may or may not be based on 
the DOM, but they're going to start by receiving an actual XML instance. 
We can use TagSoup to fudge HTML, but if you I want to handle MathML, 
SVG, and other things in it, That instance had better be namespace 
well-formed, and it had better use the right names for the right things, 
both local and qualified.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] The problems with namespaces in text/html

[Anne van Kesteren]

On Sat, 04 Nov 2006 22:56:35 +0100, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:
I've no idea about XForms, but the plan for MathML is that you can  
write it without bothering about namespaces, but that it ends up having  
namespaces in the DOM.


Then this is what I feared, and it's not sensible. Enabling mixed  
HTML/MathML to be processed with generic tools and MathML specific tools  
requires that it have the namespace, including all the necessary  
namespace attributes. [...]


Yes, exactly the reason they have the correct (MathML) namespace in the  
DOM. So they can be rendered, etc. The serialization format doesn't really  
matter.



--
Anne van Kesteren

Re: [whatwg] The problems with namespaces in text/html

[Elliotte Harold]

Anne van Kesteren wrote:

I've no idea about XForms, but the plan for MathML is that you can write 
it without bothering about namespaces, but that it ends up having 
namespaces in the DOM.


Then this is what I feared, and it's not sensible. Enabling mixed 
HTML/MathML to be processed with generic tools and MathML specific tools 
requires that it have the namespace, including all the necessary 
namespace attributes. See


http://www.elharo.com/blog/software-development/xml/2006/10/26/chameleon-schemas-considered-harmful/

for some more thoughts on this.

Folks, adding a few xmlns:math or xmlns attributes to a document just 
isn't that bad. It is in fact one of the least complex things anyone 
trying to write MathML will have to deal with. MathML has a lot worse 
than this. Ditto for XForms.


This is like making the driver's seat in a car a little more comfortable 
by ripping out the steering wheel. It makes no sense. It is a phobia 
that leads to misjudgement the relative problems with different options. 
 Namespaces do a lot more good than harm. They are necessary to the 
proper design of documents. The problem at hand is exactly what 
namespaces are designed to do. Please let them do it.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] element comments

[Anne van Kesteren]

On Sat, 04 Nov 2006 22:27:18 +0100, Matthew Raymond  
<[EMAIL PROTECTED]> wrote:

   Right. There can be differences between the initial value of an
attribute contained in markup and the instantaneous value in the DOM,
such as the case with  or ,


That's .defaultValue and .defaultSelected respectively.  
They are reflected one on one...




but with
, I can't think of a situation where the |src| value could change
from the initial value in markup. Setting the |src| attribute's
instantaneous value and setting the value in markup are one and the same
in this case.


This was not at all the issue I was raising.


--
Anne van Kesteren

Re: [whatwg] The problems with namespaces in text/html

[Anne van Kesteren]

On Sat, 04 Nov 2006 17:12:29 +0100, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:
Note that what you quoted above was not about throwing away namespaces  
but about not introducing namespace *syntax* to the text/html  
serialization. In fact, HTML5 requires UAs to put HTML elements in the  
XHTML namespace.


If all we're doing is HTML, fine. However people are now in this thread  
talking about putting MathML into this. In other forums people are  
discussing adding XForms. If I'm wrong and people are not suggesting  
that MathML and XForms and similar non-HTML things end up in the HTML  
namespace, then please tell me that. I;'d be very happy to know that.


I've no idea about XForms, but the plan for MathML is that you can write  
it without bothering about namespaces, but that it ends up having  
namespaces in the DOM.



However what I'm hearing is that people do want to mix in different  
vocabularies such as MathML and XForms without using namespaces, and  
that seems to me to be very unwise.



--
Anne van Kesteren

Re: [whatwg] Progressive rendering

[Henri Sivonen]

On Nov 3, 2006, at 07:22, Alexey Feldgendler wrote:

It's not only about printing-while-downloading. It's about the  
ability to print an arbitrarily long document without consuming  
infinite memory for DOM.


What kind of use is this about? Is this about XHTML-Print-type stuff  
or about Prince-type high-end formatting? CSS already allows page  
number references, which means that the formatter has to paginate the  
whole document in order to make forward reference by page number.


I have never seen the source of a print-only CSS formatter, but I  
imagine an optimized implementation could optimize away the DOM but  
would still have to keep the entire CSS frame tree in memory (at  
least when there's generated content that depends on later page  
numbers).


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Anne van Kesteren]

On Sat, 04 Nov 2006 19:11:00 +0100, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:
Yes, that's accurate; but there is new opportunity here. CSS, XSLT, and  
JavaScript present the option to specify styling for unknown elements,  
in the same or different namespaces.


Must-ignore could become "Must-ignore unless the stylesheet says not  
to". I'm not sure if this is really a good idea or not, but I for one  
would find it very useful and make heavy use of it.


This is already how things work. It's just that parsing of unknown  
elements works differently accross browsers.



--
Anne van Kesteren

Re: [whatwg] element comments

[Matthew Raymond]

Lachlan Hunt wrote:
> Ian Hickson wrote:
>> On Fri, 3 Nov 2006, Anne van Kesteren wrote:
>>> * It should probably mention 'img.src = foo' (that loading directly 
>>> starts). I thought that 'img.setAttribute("src", foo)' even did 
>>> different things in browsers (when the element is not yet inserted into 
>>> the document) so reflect might not be accurate.
>> I couldn't find a difference. Any idea what it was?
> 
> I don't know of any difference and I don't think there should be any, 
> even if some implementations currently do.  It would only be confusing 
> for authors if they behaved differently.

   Right. There can be differences between the initial value of an
attribute contained in markup and the instantaneous value in the DOM,
such as the case with  or , but with
, I can't think of a situation where the |src| value could change
from the initial value in markup. Setting the |src| attribute's
instantaneous value and setting the value in markup are one and the same
in this case.

Re: [whatwg] JSON encoding

[Alfonso Baqueiro]

Here is the document that explains prototype.js and its extensionshttp://www.sergiopereira.com/articles/prototype.js.html
2006/11/4, Ian Hickson <[EMAIL PROTECTED]>:(I couldn't work out what thread this was a continuation to -- the first
message below didn't have a "Re:" in the subject line, and I can't findany other thread that used the word "hazard". So I don't know exactlywhat this thread was about. However, I shall not let that stop me from
jumping in and giving my two cents...)On Fri, 3 Nov 2006, Douglas Crockford wrote:>> This is a convenience issue. Having toJSONString as a builtin is a> convenience, removing the need to load 
json.js.Assuming the thread is about introducing a way to convert a JS object intoa JSON representation, then I would encourage you to contact theECMAScript committee. Adding features to _javascript_ is out of scope for
the WHATWG specs.--Ian Hickson   U+1047E)\._.,--,'``.fLhttp://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] JSON encoding

[Alfonso Baqueiro]

My two cents as you say:2006/11/4, Ian Hickson <[EMAIL PROTECTED]>:
(I couldn't work out what thread this was a continuation to -- the firstmessage below didn't have a "Re:" in the subject line, and I can't findany other thread that used the word "hazard". So I don't know exactly
what this thread was about. However, I shall not let that stop me fromjumping in and giving my two cents...)On Fri, 3 Nov 2006, Douglas Crockford wrote:>> This is a convenience issue. Having toJSONString as a builtin is a
> convenience, removing the need to load json.js.Assuming the thread is about introducing a way to convert a JS object intoa JSON representation, then I would encourage you to contact theECMAScript committee. Adding features to _javascript_ is out of scope for
the WHATWG specs.Well, I think adding features to _javascript_ is part of its own nature, we can add features using the prototype without consulting any comitee, thats powerfull and also could be a source imcopatibility between libraries, consider the 
prototype.js library, it really extend the language.http://prototype.conio.net/dist/prototype-1.4.0.js
--Ian Hickson   U+1047E)\._.,--,'``.fLhttp://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Footnotes, endnotes, sidenotes

[Sander Tekelenburg]

At 17:53 +0100 UTC, on 2006-10-31, Håkon Wium Lie wrote:

[...]

> W3C recently published a proposal on how to achieve
> footnote/endnote presentations using the same markup [1]. The proposal
> is quite simple. Given this markup:
>
>   ..
>
> you would achieve footnoes with:
>
>   .note { position: footnote }
>
> ane endnotes with:
>
>   .note { position: endnote }

I miss the semantic aspect.  has no meaning. Something like
 would have. Once that's in place, I suppose you could indeed
offer CSS mechanisms to suggest a presentation as footnote, endnote, whatever.

Btw, I can perhaps vaguely imagine what display:footnote might look like, but
I have no clue what position:footnote might look like. I feel that this sort
of thing needs to be *much* more obvious from a spec, or else only a minute
elite will actually use such features (which in turn will give browser
vendors a reason to not even bother implementing support).

Another problem I have when thinking about the ideal spec for this is that
footnote seems to me very much a print concept, where you have a clear
concept of "page". With a screen presentation however, there's the question
whether end of page == end of document, or whether it is the end of the
window (and scrolling takes you to the next 'page').

I mention this because I can imagine that in some situations you'd want notes
to appear at the end of the document, but in other situations it might work
better to have them at the bottom of the window, or at the end of a
chapter/section, which doesn't necessarily equal the end of the document.

Also, given the realities of scrolling, I think a useful implementation would
require a mechanism that allows the user to navigate back from the footnote
to the point in the text that references it. I'm not sure what mark-up this
would require though, especially given that a footnote might be referenced to
from different points of the text. Possibly an anchor-like mechanism would be
simplest, as it would allow a UA to allow the user to simply hit the back
button. (Althought that assumes the UA would go back to the specific point in
the page where the user was before -- some UAs instead still go back to the
top of that page.)

Another thought: it seems to me that something along the lines of the
longdesc attribute[*] might be useful for annotational purposes. The only
implementation I'm aware of is iCab's, which provides access to it through
its contxtual menu and loads the expanded description in a new window. That
too makes it easy for users to return to where they were. The downside of
longdesc of course is that it requires a separate Web page, which would
exclude the possibility of presentating the annotation in the same page.
Perhaps an longdesc-like annotation element should therefore require an
anchor (pointing to an ID within the current page), not allow URLs that point
to external documents.


[*] 


-- 
Sander Tekelenburg, 

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Elliotte Harold]

Paul Topping wrote:

Elements whose namespaces aren't known should be handled like any other
unknown HTML element. I believe the common way for user agents to handle
an unknown element is basically to ignore the tag and its attributes and
treat any text between start and end tags as if the tags weren't there.
Namespaces do not present any new challenge in this area. 


Yes, that's accurate; but there is new opportunity here. CSS, XSLT, and 
JavaScript present the option to specify styling for unknown elements, 
in the same or different namespaces.


Must-ignore could become "Must-ignore unless the stylesheet says not 
to". I'm not sure if this is really a good idea or not, but I for one 
would find it very useful and make heavy use of it.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] element comments

[Alexey Feldgendler]

On Sat, 04 Nov 2006 19:43:02 +0600, Spartanicus  
<[EMAIL PROTECTED]> wrote:


The problem with allowing omission of alt depends on the meaning of  
 without alt. If  without alt is defined to mean the same as  
 with alt="", then the problem is that all cases when people omit  
the alt attribute because they don't care will end up with mangled  
meaning.



I don't see that as changing anything. Documents containing content
images without alt content are broken regarding this aspect, and they
will remain so if  without an alt attribute is considered equal to
 elements with alt="".


 is somewhat broken in any case. If I was making it up from scratch,  
I would treat missing alt same as alt="" and define it to mean  
"semantically valuable image for which the author did not provide an  
alternative text". For purely decorative images, if such thing is to exist  
at all, I would define a separate attribute like "decorative", so that  
semantic images surely don't end up as decorative by mistake.	



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] element comments

[Alexey Feldgendler]

On Sat, 04 Nov 2006 12:42:34 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:


If  without alt is defined to mean that the image is semantically
valuable but without an alternative text, then the problem is that we
need to distinguish between empty and omitted alt in DOM somehow.



That's easy enough; the real problem is that we end up saying that
literally billions of  tags are semantically valuable when in all
likelihood they're just decorative images.

The number of  tags with a alt="" attribute is about half the number
of  tags with a src="" attribute.

(1)

There are also many  tags with alt="" which are actually semantically  
valuable (2), where alt="" has been inserted automatically by the  
authoring tool or manually by the author just to make the document pass  
formal validation. I can't say whether (1) or (2) is more widespread.



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] element comments

[Alexey Feldgendler]

On Sat, 04 Nov 2006 12:37:32 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:


* The height and width attributes as defined are completely
presentational. I don't really see any value in keeping them. Now I
suppose they have to be supported anyway, but so does .



I'm thinking of only allowing integer values, and requiring them to be
equal to the dimensions of the image, if present (and requiring both to
be present if either is present). Would people be ok with that?

The use case is giving the UA information on the dimensions of the image
before the image has been downloaded, the same as the type="" or
hreflang="" attributes on the  element give information on the
resource before the resource is fetched.


That's how these attributes could have been defined if we were designing  
HTML from scratch.


In today's browsers, specifying width and height on  different from  
the actual dimensions of the image forces the image to be resized for  
display. There is existing content which relies on this.



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Elliotte Harold]

Henri Sivonen wrote:

Note that what you quoted above was not about throwing away namespaces 
but about not introducing namespace *syntax* to the text/html 
serialization. In fact, HTML5 requires UAs to put HTML elements in the 
XHTML namespace.



If all we're doing is HTML, fine. However people are now in this thread 
talking about putting MathML into this. In other forums people are 
discussing adding XForms. If I'm wrong and people are not suggesting 
that MathML and XForms and similar non-HTML things end up in the HTML 
namespace, then please tell me that. I;'d be very happy to know that.


However what I'm hearing is that people do want to mix in different 
vocabularies such as MathML and XForms without using namespaces, and 
that seems to me to be very unwise.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Henri Sivonen]

On Nov 4, 2006, at 17:19, Henri Sivonen wrote:

I think that text/html conformance needs to be defined in such a  
way that everything that is meaningful can be conveyed through the  
SAX2 ContentHandler interface (with qNames ignored) without  
violating any explicit or implicit parts of the API contract.


And I should mention that this isn't about favoring a particular API.  
The SAX2 ContentHandler is just a practical XML API cluefulness  
benchmark, so that I don't need to talk about canonicalization,  
infoset and syntactic sugar.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Henri Sivonen]

On Nov 4, 2006, at 13:15, Elliotte Harold wrote:

We need namespaces. XML tools just don't work without them, and XML  
tools are about the only thing most developers not working for  
browser vendors have that can process this stuff. In fact, I think  
developers have voted with their feet to adopt the XML toolchain as  
the sensible way to process HTML.


I think that text/html conformance needs to be defined in such a way  
that everything that is meaningful can be conveyed through the SAX2  
ContentHandler interface (with qNames ignored) without violating any  
explicit or implicit parts of the API contract. It is unfortunate  
that the spec needs to focus on the DOM, because it is too late to  
replace the DOM in browsers with something less broken.


For interop, the behavior of browsers is specified to violate XML API  
contracts when it comes to non-conforming documents. The main problem  
that I see is writing the requirements for non-browser UAs in such a  
way that XML 1.0-based API contracts do not need to be violated but  
interop isn't harmed too much.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Henri Sivonen]

On Nov 4, 2006, at 13:07, Elliotte Harold wrote:


Ian Hickson wrote:

On Mon, 9 Oct 2006, dolphinling wrote:
I'm not saying don't add MathML to HTML. I'm saying don't add  
namespace syntax to HTML.


As I've said elsewhere, I find this viewpoint simply  
incomprehensible. Namespaces are ugly, but they're not that ugly or  
that problematic. They are also at the core of XML processing.  
Throwing out namespaces makes it  nearly impossible to process HTML  
with the very large and powerful set of XML tools.


Note that what you quoted above was not about throwing away  
namespaces but about not introducing namespace *syntax* to the text/ 
html serialization. In fact, HTML5 requires UAs to put HTML elements  
in the XHTML namespace.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] Semantics in HTML

[Henri Sivonen]

On Nov 2, 2006, at 00:17, Anne van Kesteren wrote:

On Wed, 01 Nov 2006 20:55:58 +0100, James Graham <[EMAIL PROTECTED]>  
wrote:
To take a slight detour into the (hopefully not too) abstract,  
what do people think the fundamental point of semantics in HTML is?


I think the fundamental point is allowing programmatic processing of  
documents in ways that are *useful* and that semantic markup makes  
*practical* but that would be considerably less practical with  
presentation-based heuristics *and* enabling the processing without  
those wanting to do it having to negotiate with the author (or  
enabling the author to get off-the-shelf software for processing his/ 
her own documents).


Rendering for media different from the author's primary target is  
such processing done in software controlled by others.


Indexing documents and taking extracts for display in search results  
is such processing done in software controlled by others.


Generating a table of contents could be a case of the author wanting  
to get off-the-shelf software that works with his/her own documents.


So I think the merit of semantic elements in HTML should not be  
judged in terms of the willingness of semanticists to express stuff  
but instead the merit should be judged against the willingness of  
software developers to write software that consumes the expression  
for a useful purpose and the whether authors in general are  
incentivized to support such processing (either knowingly or as a  
side effect of accomplishing other goals).



Those elements should then not have any presentational aspect


Why not?

To serve media-independent presentation, having reasonable  
presentations for different media is more useful than having a  
semantic definition.


(What kinds of different media there can be is limited by how you can  
deliver data into a human. In the absence of direct-to-brain  
transfers, you are in practice limited to visual, aural and tactile  
media.)



We probably don't want things like:

  Stargate Atlantis


Although I suppose that at some point you do want to able to  
express the latter.


I think we should not care if someone wants to *express* it unless  
there is notable practical interest in *consuming* the expression.  
(Not "would be cool" interest but "would write software" interest.)


Henri has been talking about the possibility of making HTML5 more  
"semantically lax", and here Anne is interested in where it is not  
"semantically pure", presumably with a desire to fixing it.


My point is that if the semantics for a given element are not precise  
enough or authors aren't incentivized to use them properly so that  
non-presentation use of the semantics becomes impossible or  
prohibitively impractical, what is left is use for media-independent  
rendering and at that point it is enough define the element in terms  
of default presentation or, if the element doesn't have a  
distinguishing default presentation, not include the element.


Example with existing markup:
 has a well-understood default presentation (at least for visual  
media), but on the real Web, it doesn't have precise enough semantics  
to allow heuristic-free reasoning such as compiling a search database  
of definitions for words by scraping the Web. Yet,  is useful for  
achieving a particular kind of organization of pieces of text (list  
of items where the items have an inline label and a block of text) in  
a backwards-compatible way that works even in unstyled HTML.   
Therefore, it is useful to have  around as a media-independent  
grouping device that doesn't have profound semantics.


Example against introducing new markup:
In discussions where  is assumed to be axiomatically evil and  
semantic alternatives are sought, it often comes up that in text  
discussing biology the taxonomical Latin names of organisms are  
italicized. Should HTML have an element for marking up a piece of  
text as a biological taxonomical name? I say no. For data mining  
(including search engines) it is easier to compile a list of known  
taxonomical names and compare strings against that list than to  
badger every biologist to use the semantic element. As for  
presentation,  works just fine. The effects of  on aural or  
tactile media probably won't be so bad that most authors would be  
willing to take special steps. For authors themselves getting off-the- 
shelf software that does useful things, the case is probably too  
specific and lacks processing use cases to create a market. However,  
what authors might want to do is to use the taxonomical names as  
terms in an index in print. However, for that use case to cover  
different kinds of text with index terms, you'd want something more  
generic than markup for biological taxonomical names. (An index is  
not needed for interactive screen media, because you can search for  
any string anyway.)


[...] I also don't know which view best fits my position because I  
don't really unde

Re: [whatwg] element comments

[Spartanicus]

On Fri, 03 Nov 2006 19:38:37 +0600, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:

>> * Regarding the alt attribute, wouldn't it make sense to just allow it to
>> be omitted? In terms of meaning it seems the same.

I have always considered requiring the alt attribute resulting in the
use of alt="" as an anomaly.

>> On the other hand, it
>> probably shows the difference between people who thought of the
>> alternative representation and people that haven't.

Many authoring tools generate alt="" by default, mine does. It is then
up to the coder to do the right thing, but the tool will frequently not
prompt him to do so. For that reason I don't think that the presence of
alt="" can reasonably be considered as having been a conscious decision.

I'm note sure if a UA treating the absence of an alt attribute
differently from alt="" would benefit a user.

"Alexey Feldgendler" <[EMAIL PROTECTED]> wrote:

>The problem with allowing omission of alt depends on the meaning of  
>without alt. If  without alt is defined to mean the same as  with 
>alt="", then the problem is that all cases when people omit the alt attribute 
>because they don't care will end up with mangled meaning.

I don't see that as changing anything. Documents containing content
images without alt content are broken regarding this aspect, and they
will remain so if  without an alt attribute is considered equal to
 elements with alt="".

-- 
Spartanicus

(email whitelist in use, non list-server mail will not be seen)

Re: [whatwg] element comments

[Spartanicus]

Matthew Raymond <[EMAIL PROTECTED]> wrote:

>Michel Fortin wrote:

>> Except that, contrary to bgcolor, the height and width attributes can  
>> help solve a real problem: page jiggling while the images loads. It's  
>> somewhat like the type="image/jpg" attribute you can set for links:  
>> it gives advance information on what the external content is supposed  
>> to be.
>
>  So does CSS, as you point out below.

Indeed, but then there is the mantra that CSS should be considered 100%
optional since the CSS may not be used for various reasons like network
trouble. 

Afaics the question then seems to be; is preventing reflows a serious
enough issue to not delegate it to CSS?

>   The |width| and |height| attributes don't specify the dimensions of
>the source image. They specify the size of the image in the document.
>That's presentational, in my book. Arguing that those attributes are
>properties of the image within the document amounts to a free pass for
>all presentational markup. The , ,  and  elements
>communicate a property of the text, not the presentation. I don't buy
>it. Without the attributes actually describing a property of the source
>image (which is redundant), the |height| and |width| have no semantic
>meaning. Convenient as they are, they're styling as markup.

I don't believe that using a strict presentational vs semantic model is
helpful or even possible, nor do I believe that allowing width & height
attributes could create a precedent.

The question should be if maintaining these serves a valid useful
purpose.

-- 
Spartanicus

(email whitelist in use, non list-server mail will not be seen)

Re: [whatwg] element comments

[Spartanicus]

Ian Hickson <[EMAIL PROTECTED]> wrote:

[width and height attribute on the  element]

>I'm thinking of only allowing integer values, and requiring them to be 
>equal to the dimensions of the image, if present (and requiring both to 
>be present if either is present). Would people be ok with that?

Definitely on the integer value only, allowing percentage values makes
no sense to me.

In some cases I have used just one attribute
http://homepage.ntlworld.ie/spartanicus/fit_image_in_column2.htm , but
on examination this does not only have no benefit, it needlessly causes
the single coded image size to be reserved in the flow if for example a
graphical client is configured to not initially retrieve images. When
omitting both attributes the element's size collapses to the size of the
alt content, whilst the reflow on a possible subsequent retrieval of the
image occurs anyway in this particular scenario.

Meanwhile allowing authors to omit width & height together caters for
situations where better functionality is achieved if the natural
dimension of the image isn't reserved on the initial flow layout. The
required reflow on a subsequent retrieval of the image can be considered
preferable compared to the alternative where potentially valuable screen
space may be wasted to reserve space in the initial flow for the natural
size of the image.

So I also support requiring both to be present if either is present.

But wouldn't requiring the width & height values to be equal to the
natural dimension of the image require conformance checkers to have a
capability to parse images to retrieve these values?

-- 
Spartanicus

(email whitelist in use, non list-server mail will not be seen)

Re: [whatwg] element comments

[Henri Sivonen]

On Nov 4, 2006, at 08:37, Ian Hickson wrote:


I'm thinking of only allowing integer values, and requiring them to be
equal to the dimensions of the image, if present (and requiring  
both to

be present if either is present). Would people be ok with that?


What about non-square pixels in the image file? Both GIF and PNG  
allow pixel aspect ratios other than 1:1. I don't have test cases and  
I don't know what browsers do.


Also, such a requirement would make document conformance dependent on  
resources other than the (X)HTML5 file itself. Is that a good idea?  
Is the document conforming, not conforming or undecided if there are  
no other errors but the image cannot be retrieved? What image formats  
should a conformance checker know about? GIF, PNG and JFIF?


Sniffing the pixel dimensions (without the aspect ratio) out of GIF  
or PNG is both easy and efficient if the conformance checker can  
assume that image files are conforming and don't need to be fully  
decoded. JFIF looks harder.



* Perhaps we can allow content for XML documents?


That's tempting. We'd have to allow it for HTML too (via DOM
manipulation). I'm not sure, though.  is pretty buggy,  
wouldn't

this just cause  to get those bugs?


Also, it would cause further divergence between the serializations...

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] The problems with namespaces in text/html

[Lachlan Hunt]

Elliotte Harold wrote:

Ian Hickson wrote:
Some pages even have completely bogus namespaces on the root  
element, which would make the entire page screw up. 


Let the page screw up. The author will notice it and fix it. That's like 
saying some people mistype table as tabel and therefore we shoudl accept 
both spellings.


No, that's not how it works in the real world.  The users and/or author 
will find that the site no longer works, even though it used to.  They 
will then complain to the browser vendor, who will politely refuse to do 
anything about it.  The user and author will then switch back to the old 
version, which does work, or switch to a new browser.  The browser 
vendor will realise what a terrible mistake they've made and revert back 
to their old behaviour.


--
Lachlan Hunt
http://lachy.id.au/

Re: [whatwg] element comments

[Rimantas Liubertas]

>> * The height and width attributes as defined are completely
>> presentational. I don't really see any value in keeping them. Now I
>> suppose they have to be supported anyway, but so does .

I disagree.  Specifying the size is very good for incremental rendering,
but the alternatives are awful.


+1 on that.



1. 

The style attribute is far more presentational than the height and width
attributes.

2. 

#foo { height: 100px; width: 100px; }

This is simply not feasible in most cases, unless there are very few
images on the site.  Think about flickr, it just wouldn't be possible to
specify the dimensions of all their images in a stylesheet.


Another thing is that with height and width attributes information
about image size is
available at once, when in case of CSS it is available only after
stylesheet file is loaded
and parsed.
As for  style="..." I wish there wasn't such thing...


Regards,
Rimantas
--
http://rimantas.com/

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Elliotte Harold]

Ian Hickson wrote:

Some pages even have completely bogus namespaces on the root  
element, which would make the entire page screw up. 


Let the page screw up. The author will notice it and fix it. That's like 
saying some people mistype table as tabel and therefore we shoudl accept 
both spellings.


Even worse, Office 
HTML, of which there is a LOT on the Web, uses namespaces in a way to 
trigger IE to do one thing, but relies on the other browsers *not* 
handling the namespaces to make sure it all works everywhere. 


Can you elaborate on the specifics? If it's their custom office 
namespaces, I'm not too surprised.


Are there any reasons besides ease of use and misuse in tag-soup content 
that XML's namespace syntax shouldn't be added to HTML?


I can't think of any other reasons off-hand, no. But those reasons are so 
big that I find it difficult to think of anything but those problems when 
I consider namespaces, so it might just be that I'm not thinking clearly 
enough to see the other problems.



I'm sorry. Those reasons are *TRIVIAL*. They are easily handled, and 
easily fixed. This isn't even close to some of the other things that 
have been successfully introduced to th Web in the last 10 years like 
JavaScript, CSS, tables, or frames. This is like being scared of a 
mouse, while ignoring the ravenous tiger behind your back.


We need namespaces. XML tools just don't work without them, and XML 
tools are about the only thing most developers not working for browser 
vendors have that can process this stuff. In fact, I think developers 
have voted with their feet to adopt the XML toolchain as the sensible 
way to process HTML. We must not throw the entire community of people 
who want to write code to generate and process Web pages over the side 
just to make life a teeny bit easier for people who hand author HTML in 
text editors.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: [whatwg] The problems with namespaces in text/html (Was: MathML-in-HTML5)

[Elliotte Harold]

Ian Hickson wrote:

On Mon, 9 Oct 2006, dolphinling wrote:
I'm not saying don't add MathML to HTML. I'm saying don't add 
namespace syntax to HTML.


As I've said elsewhere, I find this viewpoint simply incomprehensible. 
Namespaces are ugly, but they're not that ugly or that problematic. They 
are also at the core of XML processing. Throwing out namespaces makes it 
 nearly impossible to process HTML with the very large and powerful set 
of XML tools.


Eliminating namespaces is possible (though not desirable) if all you 
want is HTML+a few more random elements; but if you're talking about 
integrating MathML, XForms, SVG, and other applications into web pages, 
then namespaces is critical and indispensable. The benefits are worth 
the costs.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

[whatwg] Image() constructor

[Anne van Kesteren]

Just so I don't forget to ask this. Are you sure the arguments are  
unsigned long? Just wondering because the height and width attributes can  
have percentages as values.



--
Anne van Kesteren

Re: [whatwg] element comments

[Anne van Kesteren]

On Sat, 04 Nov 2006 07:37:32 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

* It should probably mention 'img.src = foo' (that loading directly
starts). I thought that 'img.setAttribute("src", foo)' even did
different things in browsers (when the element is not yet inserted into
the document) so reflect might not be accurate.


I couldn't find a difference. Any idea what it was?


From what I recall setting the DOM attribute on a newly created element  
(not appending it to the DOM) would cause download immediately in all  
browsers, but some browsers acted differently when the "src" content  
attribute was set on the newly created element. As in, the download  
started the moment it was appended to the DOM, not before (no load event  
would fire).


At least the section is clearer now in terms of events. That's nice!



* The height and width attributes as defined are completely
presentational. I don't really see any value in keeping them. Now I
suppose they have to be supported anyway, but so does .


I'm thinking of only allowing integer values, and requiring them to be
equal to the dimensions of the image, if present (and requiring both to
be present if either is present). Would people be ok with that?


If you require this only for images with known intrinsic dimensions than  
that would be fine with me (as in, for some cases of SVG the requirements  
are likely different).


(To clarify, where I said "as defined" in my original message I meant "as  
currently defined". There could certainly be a use case for them just as  
there's a use case for them with the  element.)




* Perhaps we can allow content for XML documents?


That's tempting. We'd have to allow it for HTML too (via DOM
manipulation). I'm not sure, though.  is pretty buggy, wouldn't
this just cause  to get those bugs?


Is the buggyness in fallback or just because  does a lot?


--
Anne van Kesteren

Re: [whatwg] Custom elements and attributes

[Henri Sivonen]

On Nov 3, 2006, at 23:40, Øistein E. Andersen wrote:


On 31 Oct 2006, at 11:46AM, Henri Sivonen wrote:

If you add custom *elements* and use the HTML parser, the system  
does not
ensure that the custom elements would not adversely interact with  
tag inference
or error handling in browsers. [...] If you add custom elements,  
you just have to
know what you are doing in order to keep the results useful for  
the purpose of

authoring for browsers.


My idea was to allow custom elements only in contexts where such  
problems do not occur.


Right, but currently you have to know what those contexts are.

I was therefore surprised to realise that the current HTML5 draft  
seems to allow any
character except \0. Unless I have missed something, the character  
repertoire
should probably be restricted somewhat, possibly to the common  
subset allowed

in both HTML 4.01 and XML 1.0'.


I think conforming text/html documents should not be allowed to parse  
into a DOM that contains characters that are not allowed in XML 1.0.  
However, it is still necessary to decide what to do with non- 
conforming cases in browsers. I am inclined to prefer replacement  
with U+FFFD over putting stuff in the DOM that could not end up in  
there by parsing an XML 1.0 document. But of course, there's the  
issue of what existing browsers do already. :-/


Actually, I should have said that the minimum condition that I  
think is
necessary for a name of a custom attribute or element to be  
reasonable is that

the name matches the NCName production from Namespaces in XML 1.0


I agree with the intention that names should be restricted to  
(mostly) letters and
digits, and this is probably the only usable definition we will get  
any time soon.


It's not because I want to restrict names to letters and digits. I  
don't. It is for compatibility with the XML 1.0 serialization. I do  
want conforming HTML5 documents to have an XHTML5 serialization.



and only contains characters from the Basic Latin (ASCII) block.


Is this because of case-folding issues?


Yes.

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

[whatwg] colspan="0"

[Henri Sivonen]

None of Opera 9.02, Firefox 2.0, IE7 and Safari 2.0.4 implement  
colspan="0" as specified in HTML 4.01. Trident, Presto and WebKit at  
least agree on what to do with it: they treat it like colspan="1".


I suggest that only positive integers be conforming and that non- 
conforming values be treated as 1.


Test case:
http://hsivonen.iki.fi/test/wa10/tables/colspan-0.html

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] element comments

[Lachlan Hunt]

Ian Hickson wrote:

On Fri, 3 Nov 2006, Anne van Kesteren wrote:
* It should probably mention 'img.src = foo' (that loading directly 
starts). I thought that 'img.setAttribute("src", foo)' even did 
different things in browsers (when the element is not yet inserted into 
the document) so reflect might not be accurate.


I couldn't find a difference. Any idea what it was?


I don't know of any difference and I don't think there should be any, 
even if some implementations currently do.  It would only be confusing 
for authors if they behaved differently.


* I would also suggest to put "If the src attribute is omitted, there is 
no alternative image representation." after the last statement on the 
alt attribute.


Done. (I think. I edited a bunch of stuff before reading your comment so 
it may be not quite what you meant.)


And, as I mentioned in IRC, I think it should be defined that the value 
should resolve to a valid URI for an image, so that  
isn't conforming, except in this rare case:




* Regarding the alt attribute, wouldn't it make sense to just allow it 
to be omitted? In terms of meaning it seems the same. On the other hand, 
it probably shows the difference between people who thought of the 
alternative representation and people that haven't.


Maybe. I dunno.


Screen readers have a reason to to distinguish between these cases.
When an author fails to specify any alt text, users can make the screen
reader read the file name or, if it's a link, the URI so that the user
has a better chance of guess what it's for.  I could be wrong, but I
think when alt="" is explicitly specified, screen readers ignore it.

* I think it would also make sense to show some more examples for the 
alt attribute. http://www.cs.tut.fi/~jkorpela/html/alt.html might be too 
large to be included in the specification, but guidelines to that effect 
would be more than welcome.


Noted.


The explanations you've written in this are good also.

http://hixie.ch/advocacy/alttext

The house example under argument #3 would be good to include.

* The height and width attributes as defined are completely 
presentational. I don't really see any value in keeping them. Now I 
suppose they have to be supported anyway, but so does .


I disagree.  Specifying the size is very good for incremental rendering, 
but the alternatives are awful.


1. 

The style attribute is far more presentational than the height and width 
attributes.


2. 

#foo { height: 100px; width: 100px; }

This is simply not feasible in most cases, unless there are very few 
images on the site.  Think about flickr, it just wouldn't be possible to 
specify the dimensions of all their images in a stylesheet.


I'm thinking of only allowing integer values, and requiring them to be 
equal to the dimensions of the image, if present (and requiring both to 
be present if either is present). Would people be ok with that?


I agree.  Any use case for specifying percentages should be done with CSS.


* Perhaps we can allow content for XML documents?


That's tempting. We'd have to allow it for HTML too (via DOM 
manipulation).


It's already possible via DOM manipulation (except in IE which throws an 
exception).  The spec should at least define what it means and how to 
process it, even if it's defined that UAs should just ignore it.


 I'm not sure, though.  is pretty buggy, wouldn't 
this just cause  to get those bugs?


Maybe.  We'd have to get feedback from implementers.  The limitations 
and bad design of alt have been complained about quite often, this could 
be an opportunity to fix it.


This could be useful in XHTML:

foo bar

That could give a richer fallback for newer UAs and the plain text 
fallback in current XHTML UAs.  That technique could help with the 
transitional period until UAs were upgraded.  Although,  already 
provides a similar abilities.


--
Lachlan Hunt
http://lachy.id.au/