Re: [whatwg] Thoughts on HTML 5

[James Graham]

[EMAIL PROTECTED] wrote:

Lachlan had commented that "irrelevant" could be changed dynamically to
indicate parts of an application that may be relevant only during particular
points in time. I don't see how this is any different from hiding content
that isn't necessary.


Presumably a non-visual UA could use the irrelevant attribute to distinguish 
content that was not relevant at the current time from content that was merely 
being hidden from graphical UAs. I seem to remember (but I am far from being an 
expert) that currently aural browsers ignore display:none content and so 
best-practice for adding additional text for aural UAs is to use CSS positioning 
to move it out of the viewport. @irrelevant seems to provide a way to move away 
from this kind of crazy hack.



--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] Thoughts on HTML 5

[html]

Screen readers currently ignore elements with styles of display:none and 
visibility:hidden. In order to hide elements from the screen but allow screen 
readers to see them, we typically use tricks such as text-indent:-1 and 
such.

I would like something to indicate that text should not be rendered by the UA 
but still remain accessible. Content that should be available to screen readers 
but not have a visual representation is, in fact, relevant. It's relevant in 
that it gives additional information to non-sighted users that is probably 
visually indicated to those who can see.

If accessibility is the point of the "irrelevant" attribute, then it fails.

-Nicholas




>[EMAIL PROTECTED] wrote:
>> Lachlan had commented that "irrelevant" could be changed dynamically to
>> indicate parts of an application that may be relevant only during 
>particular
>> points in time. I don't see how this is any different from hiding content
>> that isn't necessary.
>
>Presumably a non-visual UA could use the irrelevant attribute to distinguish 
>content that was not relevant at the current time from content that was merely 
>
>being hidden from graphical UAs. I seem to remember (but I am far from being 
>an 
>expert) that currently aural browsers ignore display:none content and so 
>best-practice for adding additional text for aural UAs is to use CSS 
>positioning 
>to move it out of the viewport. @irrelevant seems to provide a way to move 
>away 
>from this kind of crazy hack.
>
>
>-- 
>"Eternity's a terrible thought. I mean, where's it all going to end?"
>  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] Thoughts on HTML 5

[Dave Hodder]

[EMAIL PROTECTED] wrote (with snippage):

*   I understand the concept of the  element but it's named completely wrong. The point 
is to markup a conversation between two or more parties. The problem is that the word "dialog", 
when in used in user interfaces, refers to small windows that can be interacted with. When I first read 
about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of 
the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to 
find out that wasn't the intent. I'd rename this element as  or  to 
avoid such misunderstandings.


I was confused by the name of the "dialog" element in exactly the same 
way you were, originally thinking it was to do with pop-up dialogue 
boxes.  The HTML 4 spec states:


Another application of DL, for example, is for marking up
dialogues, with each DT naming a speaker, and each DD containing
his or her words.

... which I presume influenced the addition of this element.  If there 
is a lot of dialogue marked up on the Web it deserves its own element, 
if not I guess DL could be considered to stand for "dialogue list" in 
addition to "definition list".



*   I'd like to see a common attribute that can be used on any element to indicate information 
related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a 
very common need to include extra data related to an element. I'd propose a "reldata" 
attribute (short for "related data") be considered as an optional attribute on all 
elements. We then, as developers, could use that attribute as we see fit and the document would 
still validate (for people who care about such things).


I'm not entirely sure I understand, but if you want to further define 
the semantics of an element or make it more "specialised", another group 
 has put forward the idea of a "role" attribute 
.


Regards,

Dave

Re: [whatwg] Thoughts on HTML 5

[html]

Yes, I believe the  element is supposed to be a disambiguation of the 
 element, which has previously been used for both conversations and 
definition lists. It makes sense to have separate ones since there's no way to 
tell what a  represents now. That being said, I still feel the tag name 
"dialog" is too confusing to use. Perhaps the "role" attribute would be 
appropriate to use on , such as ?

As for my suggestion of "reldata", my intent is to use the attribute for any 
type of data related to the element. The "role" attribute is intended to be 
used (from my understanding) to designate what role the element is playing on 
the page. This is not an appropriate place to put extra data that isn't 
necessary for the rendering or understanding of the element. My thought is 
doing something like this:



The data format could be whatever someone wants, plain text, structured text, 
JSON...whatever you need. The point is to have a common place to dump extra but 
related data that isn't important to the understanding of the element. I often 
use custom attributes for this now, but it would be nice to have an official 
attribute for this purpose.

-Nicholas





>[EMAIL PROTECTED] wrote (with snippage):
>> *   I understand the concept of the  element but it's named 
>completely wrong. The point is to markup a conversation between two or more 
>parties. The problem is that the word "dialog", when in used in user 
>interfaces, refers to small windows that can be interacted with. When I first 
>read about this element, I assumed it was a way to indicate that part of the 
>page is a dialog window outside of the normal flow of the document (which I 
>thought was cool). After reading the rest, I was disappointed to find out that 
>wasn't the intent. I'd rename this element as  or  
>to avoid such misunderstandings.
>
>I was confused by the name of the "dialog" element in exactly the same 
>way you were, originally thinking it was to do with pop-up dialogue 
>boxes.  The HTML 4 spec states:
>
> Another application of DL, for example, is for marking up
> dialogues, with each DT naming a speaker, and each DD containing
> his or her words.
>
>... which I presume influenced the addition of this element.  If there 
>is a lot of dialogue marked up on the Web it deserves its own element, 
>if not I guess DL could be considered to stand for "dialogue list" in 
>addition to "definition list".
>
>> *   I'd like to see a common attribute that can be used on any element 
>to indicate information related to the element. I'm tired of fighting the 
>custom attribute battle. The fact is that it's a very common need to include 
>extra data related to an element. I'd propose a "reldata" attribute (short for 
>"related data") be considered as an optional attribute on all elements. We 
>then, as developers, could use that attribute as we see fit and the document 
>would still validate (for people who care about such things).
>
>I'm not entirely sure I understand, but if you want to further define 
>the semantics of an element or make it more "specialised", another group 
>  has put forward the idea of a "role" attribute 
>.
>
>Regards,
>
>Dave

Re: [whatwg] Thoughts on HTML 5

[Smylers]

[EMAIL PROTECTED] writes:

> I had posted this on my personal blog:
> http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
> I join the mailing list to continue the discussion, so here it is:

Hi there Nicholas.  Welcome to the list, and thanks for your comments.
I'll try to explain the purpose of elements that you are questioning.
Where I've snipped a point you made that's generally because I
agree with you and have nothing further to add.

> * the irrelevant attribute ... I can't imagine ever using it.

That's OK -- it isn't necessary for every author to use every element!
It's purpose is for use on interactive pages, where some things only
appear (or disappear), using JavaScript, after the user has done
something.

> Lachlan had commented that "irrelevant" could be changed dynamically
> to indicate parts of an application that may be relevant only during
> particular points in time.

For example think of an error message which appears if the user tries to
submit invalid input: when the page initially loads the error message
isn't relevant (no error has yet occurred), but it's in the document so
that it's there if needed.  At that point the script that's detected the
error condition can set irrelevant to false on the error message.

> I don't see how this is any different from hiding content that isn't
> necessary.

It _isn't_ different from that; it's exactly that!  It's providing a
mechanism for doing precisely that -- in HTML 4 there isn't a way of
marking up an element as being hidden.

>   The spec says, "When specified on an element, it indicates that the
>   element is not yet, or is no longer, relevant. User agents should
>   not render elements that have the irrelevant  attribute specified."
>   If it's not relevant, why is it in the page in the first place?

So that it can become relevant in response to events.

> * I'm not sure what the  element offers over the 
>   element. I thought the purpose of the  was to indicate a
>   section of the page. If there's not a clear distinction between
>   these elements, I don't see the need for a second one.

 is semantically neutral; it just means that there's a division
(the author needed a block element) but doesn't give a reason for it --
similarly to how  merely denotes a run of text without giving a
reason.

In HTML 4 it's rare to need to resort to , because there are many
other elements for denoting a span of text for a particular purpose
(, , , etc).

Along similar lines HTML 5 provides a block elements for specific
purposes, so that different sorts of blocks can be marked up
differently.   is one of those.

A  is not merely any block division that the author needed to
make on the page (probably to hang some styles off), but is specifically
a section (or subsection) of a document.

For example consider a webpage with this design:

* a header with the site's name and logo and so on
* a left column with navigation links
* the main page content (what the reader has come here to read) in the
  middle; this is quite long, and has subheadings at various points
* a right column ('sidebar') with related information

In HTML 4 that would likely be marked up with lots of s (or a
table).  HTML 5 has meaningful elements for each of those -- ,
, , and .

Further,  can be split into s.  Possibly the sidebar
would have sections too.  Note that because of how HTML 5 infers
sections from headings it isn't necessary to include  tags to
get a section; just using , , , etc at the appropriate level
will achieve the same effect.  But sometimes explicitly marking sections
is easier.

For an example of a document which clearly has lots of sections and
subsections see the HTML 5 spec itself!

> * I'm a bit unsure of the  element. As with , it
>   seems only vaguely different from 

Many HTML 5 pages will have just one  (whereas in the HTML 4
equivalent it would be necessary for that block to be just one of
several s on the page).  That will enable user-agents to know the
'main purpose' of a page.  In particular text-based and speaking
browsers can offer to jump straight to it (something which authors have
to code by hand on each page in HTML 4).

> * The  element really pushes the boundaries of marking up
>   literary devices. ... Short asides are typically indicated by
>   parentheses and I don't see any reason not to keep doing that
>   (seriously).

Indeed, parens would still be the best thing to do there.  If no mark-up
is needed then don't bother with any.  But think of sidebars: books
often have 'boxes' out of the main flow of text describing a separate
point.  These sorts of asides obviously need some mark-up, and 
would be appropriate to use there.

> * The  is another that stresses the understanding of grammatical
>   structure for web developers. The intent is to designate the defining
>   instance of a term, abberviation, or acronym. Does that make sense to
>   you?

So far as I can tell it's defined in the way that I've always been using
it in

Re: [whatwg] Thoughts on HTML 5

[Nicholas C. Zakas]

Thanks, I'm happy to be here. :)

Thanks for a clear explanation of the irrelevant attribute. If you see the 
other thread about this, I think we've all now agreed that the purpose for the 
attribute makes sense, but the name is another story. It's difficult to spell 
for most people and really gives the wrong impression of the content. The 
suggestion was made to rename it "ignore", which I think makes more sense.

As there is also another thread going on about , I don't want to 
repeat all of my comments here, but suffice to say that I don't see why I'd 
ever use  when I get implicit sections by using  elements. 
Writers are used to headings indicating sections, and don't really think of a 
section as anything on its own. I can understand the use of  as 
semantically indicating that the area contains information rather than markup, 
but I think  is overkill.

I understand your reasoning for the  element, perhaps this is another 
element that is suffering from the wrong name. Most of web developers have no 
idea what an aside is let alone when to use one. I know that  was 
removed because it confused web developers. Given that this is the same 
audience, the ones who couldn't figure out the difference between an acronym 
and an abbreviation, do you really think that  will get used? Perhaps 
it would better be named ?

-Nicholas

- Original Message 
From: Smylers <[EMAIL PROTECTED]>
To: whatwg@lists.whatwg.org
Sent: Friday, February 29, 2008 12:02:24 AM
Subject: Re: [whatwg] Thoughts on HTML 5

[EMAIL PROTECTED] writes:

> I had posted this on my personal blog:
> http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
> I join the mailing list to continue the discussion, so here it is:

Hi there Nicholas.  Welcome to the list, and thanks for your comments.
I'll try to explain the purpose of elements that you are questioning.
Where I've snipped a point you made that's generally because I
agree with you and have nothing further to add.

> * the irrelevant attribute ... I can't imagine ever using it.

That's OK -- it isn't necessary for every author to use every element!
It's purpose is for use on interactive pages, where some things only
appear (or disappear), using JavaScript, after the user has done
something.

> Lachlan had commented that "irrelevant" could be changed dynamically
> to indicate parts of an application that may be relevant only during
> particular points in time.

For example think of an error message which appears if the user tries to
submit invalid input: when the page initially loads the error message
isn't relevant (no error has yet occurred), but it's in the document so
that it's there if needed.  At that point the script that's detected the
error condition can set irrelevant to false on the error message.

> I don't see how this is any different from hiding content that isn't
> necessary.

It _isn't_ different from that; it's exactly that!  It's providing a
mechanism for doing precisely that -- in HTML 4 there isn't a way of
marking up an element as being hidden.

>   The spec says, "When specified on an element, it indicates that the
>   element is not yet, or is no longer, relevant. User agents should
>   not render elements that have the irrelevant  attribute specified."
>   If it's not relevant, why is it in the page in the first place?

So that it can become relevant in response to events.

> * I'm not sure what the  element offers over the 
>   element. I thought the purpose of the  was to indicate a
>   section of the page. If there's not a clear distinction between
>   these elements, I don't see the need for a second one.

 is semantically neutral; it just means that there's a division
(the author needed a block element) but doesn't give a reason for it --
similarly to how  merely denotes a run of text without giving a
reason.

In HTML 4 it's rare to need to resort to , because there are many
other elements for denoting a span of text for a particular purpose
(, , , etc).

Along similar lines HTML 5 provides a block elements for specific
purposes, so that different sorts of blocks can be marked up
differently.   is one of those.

A  is not merely any block division that the author needed to
make on the page (probably to hang some styles off), but is specifically
a section (or subsection) of a document.

For example consider a webpage with this design:

* a header with the site's name and logo and so on
* a left column with navigation links
* the main page content (what the reader has come here to read) in the
  middle; this is quite long, and has subheadings at various points
* a right column ('sidebar') with related information

In HTML 4 that would likely be marked up with lots of s (or

Re: [whatwg] Thoughts on HTML 5

[Krzysztof Żelechowski]

Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:

> I understand your reasoning for the  element, perhaps this is
> another element that is suffering from the wrong name. Most of web
> developers have no idea what an aside is let alone when to use one. I
> know that  was removed because it confused web developers.
> Given that this is the same audience, the ones who couldn't figure out
> the difference between an acronym and an abbreviation, do you really
> think that  will get used? Perhaps it would better be named
> ?

"Aside" is customary in dialogue annotations, 
I have never seen any "callout".

Chris

Re: [whatwg] Thoughts on HTML 5

[Shannon]

Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:

  

Perhaps it would better be named ?



"Aside" is customary in dialogue annotations, 
I have never seen any "callout".


Chris

  

Call it . It may sound crude but it's hard to mistake its meaning.

Shannon

Re: [whatwg] Thoughts on HTML 5

[Nicholas C. Zakas]

Oooh, I like that better.

@Chris - I understand what an "aside" is, I just know for a fact that most 
people do not. Shannon's suggestion of "note" makes much more sense to me than 
my suggestion of "callout".

Long live !

-Nicholas

- Original Message 
From: Shannon <[EMAIL PROTECTED]>
To: whatwg@lists.whatwg.org
Sent: Monday, March 3, 2008 3:40:15 PM
Subject: Re: [whatwg] Thoughts on HTML 5


> Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
>
>   
>> Perhaps it would better be named ?
>> 
>
> "Aside" is customary in dialogue annotations, 
> I have never seen any "callout".
>
> Chris
>
>   
Call it . It may sound crude but it's hard to mistake its meaning.

Shannon







  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote:
>
> I've just finished taking a look at the working draft of HTML 5 and 
> thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution 
> of HTML 4, which has both its good and bad points. Accordingly, there 
> are both good and bad parts of the specification. My thoughts are as 
> follows:

(I've omitted replies to some parts of your e-mail. I have saved your 
e-mail for further replies to those sections later.)

> * I understand the concept of the  element but it's named 
> completely wrong. The point is to markup a conversation between two or 
> more parties. The problem is that the word "dialog", when in used in 
> user interfaces, refers to small windows that can be interacted with. 
> When I first read about this element, I assumed it was a way to indicate 
> that part of the page is a dialog window outside of the normal flow of 
> the document (which I thought was cool). After reading the rest, I was 
> disappointed to find out that wasn't the intent. I'd rename this element 
> as  or  to avoid such misunderstandings.

I agree that the name is suboptimal but those names are worse (they're too 
long, and they're overly specific). I'm not sure what to do about this.


> * The  is another that stresses the understanding of 
> grammatical structure for web developers. The intent is to designate the 
> defining instance of a term, abberviation, or acronym. Does that make 
> sense to you? If it did, give yourself one point; if it didn't, don't 
> feel bad, most people won't get it. Again, any element that leaves 
> people scratching their heads probably isn't necessary or useful.

 doesn't have to be used, but for certain cases it's very useful. I 
don't think it's a problem to keep it.


> * Speaking of confusing, I've read the section about the  
> element five times now and still have no idea what it's used for.

I don't know how to improve the current text. Does the example showing the 
newsgroups activity help at all?

The real reason for  is that we need to make sure people don't 
abuse  just to show gauges (e.g. disk space usage). Does that 
make sense? How should we go about better describing this?


> * I'd like to see some treatment of rich text input controls. Right 
> now we all use a hack (an iframe in design mode) that has to be copied 
> over into a form field to be submitted. It would be nice to have this 
> handled natively and have reliable HTML formatting of that content 
> (instead of the per-browser implementations we have now).
>
> Also "contenteditable" doesn't solve my issue with rich text editing. It 
> solves the ability to do it, but not a straightforward way to do it in 
> the context of a form and submit it back to the server without some 
> intermediary code. My point is that there should be a way to submit rich 
> text in a form by default, without needing to write extra JavaScript 
> code.

The problem is that while everyone seems to want a rich text control, 
nobody seems to agree on exactly what it should allow. Thus 
contenteditable, and the ability for people to roll their own.


> * I'd like to see a common attribute that can be used on any element 
> to indicate information related to the element. I'm tired of fighting 
> the custom attribute battle. The fact is that it's a very common need to 
> include extra data related to an element. I'd propose a "reldata" 
> attribute (short for "related data") be considered as an optional 
> attribute on all elements. We then, as developers, could use that 
> attribute as we see fit and the document would still validate (for 
> people who care about such things). 

We recently added data-*="", does that help?

   http://www.whatwg.org/specs/web-apps/current-work/#data-

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Paweł Stradomski]

W liście Ian Hickson z dnia wtorek 13 maja 2008:
> > * I understand the concept of the  element but it's named
> > completely wrong. The point is to markup a conversation between two or
> > more parties. The problem is that the word "dialog", when in used in
> > user interfaces, refers to small windows that can be interacted with.
> > When I first read about this element, I assumed it was a way to indicate
> > that part of the page is a dialog window outside of the normal flow of
> > the document (which I thought was cool). After reading the rest, I was
> > disappointed to find out that wasn't the intent. I'd rename this element
> > as  or  to avoid such misunderstandings.
>
> I agree that the name is suboptimal but those names are worse (they're too
> long, and they're overly specific). I'm not sure what to do about this.

Perhaps  ? Short and simple, although not exactly equal in meaning to 
.


-- 
Paweł Stradomski

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Tue, 13 May 2008, Paweł Stradomski wrote:
> W liście Ian Hickson z dnia wtorek 13 maja 2008:
> > > * I understand the concept of the  element but it's named
> > > completely wrong. The point is to markup a conversation between two or
> > > more parties. The problem is that the word "dialog", when in used in
> > > user interfaces, refers to small windows that can be interacted with.
> > > When I first read about this element, I assumed it was a way to indicate
> > > that part of the page is a dialog window outside of the normal flow of
> > > the document (which I thought was cool). After reading the rest, I was
> > > disappointed to find out that wasn't the intent. I'd rename this element
> > > as  or  to avoid such misunderstandings.
> >
> > I agree that the name is suboptimal but those names are worse (they're 
> > too long, and they're overly specific). I'm not sure what to do about 
> > this.
> 
> Perhaps  ? Short and simple, although not exactly equal in meaning 
> to .

That's probably the best suggestion so far, but I'm still not convinced 
it's really much better than . I think it has at least as many 
other interpretations (e.g. what we call a "talk" over here is really a 
slide show).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Karl Dubost]

Le 14 mai 2008 à 07:09, Ian Hickson a écrit :
That's probably the best suggestion so far, but I'm still not  
convinced

it's really much better than . I think it has at least as many
other interpretations (e.g. what we call a "talk" over here is  
really a

slide show).


food for thoughts

* 
*  (probably too long)
*   (probably too IRC, messenger oriented, though here
   I suspect my own distortion field. People often says
   "let's have a chat".)
*   (was wondering if it was less geeky than dialog, not sure)
* 
* 
* 
* 


--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

Re: [whatwg] Thoughts on HTML 5

[Krzysztof Żelechowski]

I recommend  because it refers to a conversation that has
been put down, as compared to a live  (I do not recommend
introducing the latter, of course, as HTML is not live).

Chris

Dnia 2008-05-14, śro o godzinie 11:31 +0900, Karl Dubost pisze:
> Le 14 mai 2008 à 07:09, Ian Hickson a écrit :
> > That's probably the best suggestion so far, but I'm still not  
> > convinced
> > it's really much better than . I think it has at least as many
> > other interpretations (e.g. what we call a "talk" over here is  
> > really a
> > slide show).
> 
> food for thoughts
> 
> * 
> *  (probably too long)
> *   (probably too IRC, messenger oriented, though here
> I suspect my own distortion field. People often says
> "let's have a chat".)
> *   (was wondering if it was less geeky than dialog, not sure)
> * 
> * 
> * 
> * 
> 
>   

Re: [whatwg] Thoughts on HTML 5

[Smylers]

Karl Dubost writes:

> Le 14 mai 2008 à 07:09, Ian Hickson a écrit :
> 
> > That [ is] probably the best suggestion so far, but I'm still
> > not convinced it's really much better than  . I think it has
> > at least as many other interpretations (e.g. what we call a "talk"
> > over here is really a slide show).

Indeed; as a noun a "talk" seems to refer to a presentation more often
than the action of talking.   would be less subject to
misinterpretation, but the gerund form makes an awkward tag name.

> food for thoughts
> 
> *  (probably too long)

It's more specific than 'dialogue', which might incorrectly suggest it
isn't appropriate to use it for dialogue that isn't a conversation.

> *  

Ditto, but also it's a less-well-known word and harder to spell!

> *   (probably too IRC, messenger oriented, though here
>I suspect my own distortion field. People often says
>"let's have a chat".)

People do say that.  But this element would also be the one used for
marking up Shakespeare's plays, and labelling them as "chats" seems a
touch barbaric.

> *   (was wondering if it was less geeky than dialog, not sure)

I think so, but that's because probably I'm from the UK where "dialog"
is a spelling mistake in general use, so only occurs in narrow technical
contexts.  Elsewhere HTML takes USA spellings ("color", etc), so it
would be bad to pick "dialogue" if most USA speakers would naturally
spell it "dialog".

(Though having either of them is likely to lead _some_ group to
accidentally using t'other spelling.)

> *  

Too obscure/specific.

> *  

I quite like that.  It could be misinterpreted as "a speech" rather than
"some speech", but it may be the least-bad.

> *  

More commonly it's a verb than a noun, which makes it awkward.

Smylers

Re: [whatwg] Thoughts on HTML 5

[Smylers]

Krzysztof Żelechowski writes:

> I recommend  because it refers to a conversation that has
> been put down

However many things in webpages are things which have been written down!

This is specifically a transcript of some speech -- not a transcript of
commands typed at a computer prompt, nor an exam transcript, nor any
other kind of transcript.

So focusing on the thing being transcribed, the speech, seems more
sensible; that it has been written down is something which will be
readily apparent to anybody reading it!

Smylers

Re: [whatwg] Thoughts on HTML 5

[Tab Atkins Jr.]

2008/5/13 Ian Hickson <[EMAIL PROTECTED]>:

> On Tue, 13 May 2008, Paweł Stradomski wrote:
>
 [...]

> > Perhaps  ? Short and simple, although not exactly equal in meaning
> > to .
>
> That's probably the best suggestion so far, but I'm still not convinced
> it's really much better than . I think it has at least as many
> other interpretations (e.g. what we call a "talk" over here is really a
> slide show).
>

Honestly, though, are we concerned that people will think a  element
in html refers to a slideshow?  The ambiguity of  occurs because
there is a very reasonable and natural interpretation for the element name
within the context of web applications that happens to be completely wrong.
, while certainly ambiguous in some ways, is extremely clear within
the context of a web application.  There is no other major existing entity
or idea with the same or similar name for it to clash with.

Plus, it's easy to spell, easy to remember, neither pretentious nor overly
casual (useful both for IRC and Shakespeare!), and hits the intended meaning
of the element (modulo the slight ambiguity) very well.  From what I can
tell, that's the entire checklist of objections that have been raised over
previous name suggestions.   seems to pass with flying colors.

~TJ

Re: [whatwg] Thoughts on HTML 5

[Křištof Želechovski]

"converse" is more an adjective like "opposite" to me.  Which is even more
awkward.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Smylers
Sent: Wednesday, May 14, 2008 2:12 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Thoughts on HTML 5

Karl Dubost writes:


> *  

More commonly it's a verb than a noun, which makes it awkward.

Smylers

Re: [whatwg] Thoughts on HTML 5

[Křištof Želechovski]

Commands typed at a computer prompt do form a conversation between the
commander and the executor (if the executor responds - otherwise it is good
old CODE).
On the other hand, a speech is closer to a monologue (soliloquy).
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Smylers
Sent: Wednesday, May 14, 2008 2:16 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Thoughts on HTML 5

Krzysztof Żelechowski writes:

> I recommend  because it refers to a conversation that has
> been put down

However many things in webpages are things which have been written down!

This is specifically a transcript of some speech -- not a transcript of
commands typed at a computer prompt, nor an exam transcript, nor any
other kind of transcript.

So focusing on the thing being transcribed, the speech, seems more
sensible; that it has been written down is something which will be
readily apparent to anybody reading it!

Smylers

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

(Not all of this e-mail is covered in this reply. It's possible that I 
will reply to the same points in this e-mail multiple times, for which I 
apologise in advance.)

On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote:
>
> * I'm not sure what the  element offers over the  
> element. I thought the purpose of the  was to indicate a section 
> of the page. If there's not a clear distinction between these elements, 
> I don't see the need for a second one.

Please see:
   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015506.html
...for a discussion on this matter.


> * I'm a bit unsure of the  element. As with , it 
> seems only vaguely different from  and too focused on solving the 
> question of what markup to use for a blog.

Blogs and forums and news articles, yes. Those are quite a big use case on 
the Web. :-)


> * The  element really pushes the boundaries of marking up 
> literary devices. I'm not sure enough web developers know what an aside 
> actually is. Short asides are typically indicated by parentheses and I 
> don't see any reason not to keep doing that (seriously). Any element 
> that requires someone to ask an English teacher when it should be used 
> is probably a bad idea.

There are a lot of asides on the Web. Ads, side notes, indeed almost 
anything in a sidebar other than navigation, etc.


> * The  is another that stresses the understanding of 
> grammatical structure for web developers. The intent is to designate the 
> defining instance of a term, abberviation, or acronym. Does that make 
> sense to you? If it did, give yourself one point; if it didn't, don't 
> feel bad, most people won't get it. Again, any element that leaves 
> people scratching their heads probably isn't necessary or useful.

It's an element that I use a lot in HTML5 itself. I agree that it's not a 
big target audience, as it were, but since it's already implemented it's a 
lot easier for us to add it than it would be to add other elements with 
little potential usage.


> * Speaking of confusing, I've read the section about the  
> element five times now and still have no idea what it's used for.

Do the examples not help?


> * I'd like to see some treatment of rich text input controls. Right 
> now we all use a hack (an iframe in design mode) that has to be copied 
> over into a form field to be submitted. It would be nice to have this 
> handled natively and have reliable HTML formatting of that content 
> (instead of the per-browser implementations we have now).

Sadly the problem is that while everyone agrees on the need, nobody agrees 
on exactly what the profile of HTML that should be allowed is, and short 
of including an entire schema language, there doesn't seem to be a good 
solution. The spec now gets around this by just providing a generic 
mechanism and relying on the scripts to implement whatever restrictions 
they want.


> * I'd like to see a common attribute that can be used on any element 
> to indicate information related to the element. I'm tired of fighting 
> the custom attribute battle. The fact is that it's a very common need to 
> include extra data related to an element. I'd propose a "reldata" 
> attribute (short for "related data") be considered as an optional 
> attribute on all elements. We then, as developers, could use that 
> attribute as we see fit and the document would still validate (for 
> people who care about such things).

We've added data-* for this.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Sat, 1 Mar 2008, Nicholas C. Zakas wrote:
> 
> As there is also another thread going on about , I don't want 
> to repeat all of my comments here, but suffice to say that I don't see 
> why I'd ever use  when I get implicit sections by using  
> elements. Writers are used to headings indicating sections, and don't 
> really think of a section as anything on its own. I can understand the 
> use of  as semantically indicating that the area contains 
> information rather than markup, but I think  is overkill.

I think it won't be used by everyone, but some people have indicated a 
clear desire to not have to worry about the numbering of headers.


> I understand your reasoning for the  element, perhaps this is 
> another element that is suffering from the wrong name. Most of web 
> developers have no idea what an aside is let alone when to use one. I 
> know that  was removed because it confused web developers. 
> Given that this is the same audience, the ones who couldn't figure out 
> the difference between an acronym and an abbreviation, do you really 
> think that  will get used? Perhaps it would better be named 
> ?

 might be ok, but I wanted to avoid being too specific about the 
presentation in the name.

( was removed because it's redundant with .)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Sat, 8 Mar 2008, Nicholas C. Zakas wrote:
> From: Shannon <[EMAIL PROTECTED]>
> > > Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
> > > > Perhaps it would better be named ?
> > >
> > > "Aside" is customary in dialogue annotations, I have never seen any 
> > > "callout".
> >
> > Call it . It may sound crude but it's hard to mistake its 
> > meaning.
>
> Oooh, I like that better.
> 
> @Chris - I understand what an "aside" is, I just know for a fact that 
> most people do not. Shannon's suggestion of "note" makes much more sense 
> to me than my suggestion of "callout".
> 
> Long live !

 and  aren't really generic enough. e.g. in HTML5  
would be used for both the notes and the examples in the spec, but  
would only sound like it was ok for the notes.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Shannon]

Ian Hickson wrote:

On Sat, 8 Mar 2008, Nicholas C. Zakas wrote:
  

From: Shannon <[EMAIL PROTECTED]>


Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:


Perhaps it would better be named ?
  
"Aside" is customary in dialogue annotations, I have never seen any 
"callout".

Call it . It may sound crude but it's hard to mistake its 
meaning.
  

Oooh, I like that better.

@Chris - I understand what an "aside" is, I just know for a fact that 
most people do not. Shannon's suggestion of "note" makes much more sense 
to me than my suggestion of "callout".


Long live !



 and  aren't really generic enough. e.g. in HTML5  
would be used for both the notes and the examples in the spec, but  
would only sound like it was ok for the notes.


  
I think web developers would prefer ,  , 
 or .


Shannon

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote:
>
> I had posted this on my personal blog: 
> http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested I 
> join the mailing list to continue the discussion, so here it is:

Apologies if this is the umpteenth time I've replied to this, or if I 
haven't replied to it yet. :-) My system gets confused when I have e-mails 
that cover multiple issues, as I end up copying the e-mail to each 
relevant folder and then I end up dealing with the same e-mail over and 
over. I've covered most of the points you wrote below.


> I've just finished taking a look at the working draft of HTML 5 and 
> thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution 
> of HTML 4, which has both its good and bad points. Accordingly, there 
> are both good and bad parts of the specification. My thoughts are as 
> follows:
>   
> * I almost laughed when I saw the irrelevant attribute. First, 
> because that's a word that web developers throw around a lot and second 
> because I can't imagine ever using it. The spec says, "When specified on 
> an element, it indicates that the element is not yet, or is no longer, 
> relevant. User agents should not render elements that have the 
> irrelevant attribute specified." If it's not relevant, why is it in the 
> page in the first place? Further, do you know how many people will spell 
> this wrong 100 times before they spell it right? Unless there's a deeper 
> meaning or requirement behind this attribute, I think it's just a waste 
> of a section.

I've renamed it to "hidden".


> * I'm not sure what the  element offers over the  
> element. I thought the purpose of the  was to indicate a section 
> of the page. If there's not a clear distinction between these elements, 
> I don't see the need for a second one.

 is really intended as the "last resort" element.  is 
intended to relieve it of some of its uses.


> * I'm a bit unsure of the  element. As with , it 
> seems only vaguely different from  and too focused on solving the 
> question of what markup to use for a blog.

Blogs are important. :-)


> * The  element really pushes the boundaries of marking up 
> literary devices. I'm not sure enough web developers know what an aside 
> actually is. Short asides are typically indicated by parentheses and I 
> don't see any reason not to keep doing that (seriously). Any element 
> that requires someone to ask an English teacher when it should be used 
> is probably a bad idea.

 really could be called , we just didn't want people to 
think it was only useful for asides that were on the side of the page.


> * I understand the concept of the  element but it's named 
> completely wrong. The point is to markup a conversation between two or 
> more parties. The problem is that the word "dialog", when in used in 
> user interfaces, refers to small windows that can be interacted with. 
> When I first read about this element, I assumed it was a way to indicate 
> that part of the page is a dialog window outside of the normal flow of 
> the document (which I thought was cool). After reading the rest, I was 
> disappointed to find out that wasn't the intent. I'd rename this element 
> as  or  to avoid such misunderstandings.

Unfortunately those names aren't necessarily right either. This is a 
recently reopened issue, though, so it may change, we'll see.


> * The ping attribute on the  element is a stroke of pure genius. 
> We've been left hacking solutions for click monitoring for way too long.

Just out of interest, do you have any opinion on whether ping="", as 
specified, would be something you would use?


> * The  is another that stresses the understanding of 
> grammatical structure for web developers. The intent is to designate the 
> defining instance of a term, abberviation, or acronym. Does that make 
> sense to you? If it did, give yourself one point; if it didn't, don't 
> feel bad, most people won't get it. Again, any element that leaves 
> people scratching their heads probably isn't necessary or useful.

 is used enough that it's probably worth keeping (it's in HTML4 too).


> * Speaking of confusing, I've read the section about the  
> element five times now and still have no idea what it's used for.

Is the new text better?


> * I'd like to see some treatment of rich text input controls. Right 
> now we all use a hack (an iframe in design mode) that has to be copied 
> over into a form field to be submitted. It would be nice to have this 
> handled natively and have reliable HTML formatting of that content 
> (instead of the per-browser implementations we have now).

contentEditable is being made more consistent, but there's still no 
non-scripted solution, since nobody can agree on what elements to allow.


> Also "contenteditable" doesn't solve my issue with rich text editing. It 
> solves the ability to do it, but not a straightforward way to do it in 
> the context of a 

Re: [whatwg] Thoughts on HTML 5

[Garrett Smith]

On Thu, Feb 28, 2008 at 10:31 AM,   wrote:



 We then, as developers, could use that attribute as we see fit and
the document would still validate (for people who care about such
things).
> -

Are people who care about things are the parenthetical afterthought?

Just curious: What are you expecting your invalid html and custom
attributes to do?

Garrett

>
> -Nicholas
>

Re: [whatwg] Thoughts on HTML 5

[Tab Atkins Jr.]

> On Sat, Dec 13, 2008 at 1:40 AM, Garrett Smith  wrote:
>>
>> On Thu, Feb 28, 2008 at 10:31 AM,   wrote:
>> We then, as developers, could use that attribute as we see fit and
>> the document would still validate (for people who care about such
>> things).
>
> Are people who care about things are the parenthetical afterthought?
>
> Just curious: What are you expecting your invalid html and custom
> attributes to do?

Control scripts, usually.  This is a valid and common use-case that
currently has to hack around things, sometimes by embedding this data
in the class attribute.  The data-* attribute family is explicitly
designed for this.

~TJ

Re: [whatwg] Thoughts on HTML 5

[Tab Atkins Jr.]

> You're not Nicholas. We don't know if that is what Nicholas expects
> his HTML to do or if he is expecting something else. In absence of an
> example, I can't do much more than guess. I cannot expect your
> assumptions to be correct.

Well, of course, but you sent the message to the entire group, so you
should be ready for answers from the whole group.  ^_^

> You've not stated how creating invalid HTML can "control scripts".
> Having an interest in scripting, I would like to know how this works.

Dude, come on.  You're trying to poison the dialogue here.  The point
isn't to create invalid HTML.  It's to put metadata on elements, which
is most easily accomplished through custom attributes.  This does
(currently, in HTML4) happen to be invalid, but it's hardly on the
level of your standard invalid html produced by a novice author.

As to how custom attributes can help control scripts, look into any
decent javascript plugin.  Many of them utilize some form of metadata
when interacting with the DOM.  This can be passed into the plugin via
a function call, or embedded into a nearby 

Re: [whatwg] Thoughts on HTML 5

[Garrett Smith]

On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr.  wrote:
>> You're not Nicholas. We don't know if that is what Nicholas expects
>> his HTML to do or if he is expecting something else. In absence of an
>> example, I can't do much more than guess. I cannot expect your
>> assumptions to be correct.
>
> Well, of course, but you sent the message to the entire group, so you
> should be ready for answers from the whole group.  ^_^
>
>> You've not stated how creating invalid HTML can "control scripts".
>> Having an interest in scripting, I would like to know how this works.
>
> Dude, come on.  You're trying to poison the dialogue here.  The point

Instead of a complaining about my intentions, why don't you post an
example that shows the problem (demonstrate need), how the problem is
overcome (the invalid HTML solution), and what browsers actually do?

I've seen code that has invalid attributes. These attributes won't
always have the same effect as the author wanted them to. Not all
authors expect the same thing from their invalid HTML.

Recent c.l.js discussions have included examples of page author using
a named element where that element does not support the name
attribute, e.g. . The author had expected the
element to be included with getElementsByName, but it wasn't. (not the
first time someone has expected nonstandard behavior from an
attribute). I've seen other uses of invalid HTML that did what the
author wanted to in most cases.

Valid HTML can have a clear and expected outcome. If something is done
according to standard, it can be expected that that something will
produce the outcome specified. If it doesn't, it would be your fault.

> As to how custom attributes can help control scripts, look into any
> decent javascript plugin.  Many of them utilize some form of metadata

What is a javascript plugin?

The  element is designed for associating data with a plugin,
such as a swf movie. Is this an allusion?

 Garrett

>
> ~TJ
>

Re: [whatwg] Thoughts on HTML 5

[Garrett Smith]

On Mon, Dec 15, 2008 at 6:36 PM, Garrett Smith  wrote:
> On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr.  wrote:


>
> Valid HTML can have a clear and expected outcome. If something is done
> according to standard, it can be expected that that something will
> produce the outcome specified. If it doesn't, it would be your fault.
>

(for using a non standard approach.)


Garrett

>
>  Garrett
>
>>
>> ~TJ
>>
>

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Dienstag, den 16.12.2008, 14:22 + schrieb Philip Taylor:
> On Tue, Dec 16, 2008 at 2:15 PM, Nils Dagsson Moskopp
>  wrote:
> > As I said, invalid input should be rejected in the first place. When I
> > write a blog post, I usually catch errors like this when I click on the
> > "preview" button and its all yellow.
> 
> But you still accept user input that can lead to ill-formed output,
> like in http://blog.dieweltistgarnichtso.net/?s=%ef%bf%bf :-)
> (That particular case probably doesn't affect anyone other than the
> user who enters that URL, but it's a pain whenever the user input is
> displayed back to other users or shown in admin interfaces, and very
> few people seem to implement it correctly in practice.)
Please, its Wordpress ! Those are the people that use eval() when
parsing input. I already have hacked a bit and will no doubt do
something about input as soon as my HTML5 theme based on sandbox is
ready. In the meantime, don't input this character in the comments, I've
not really thrilled to see that stuff implode.

Oh and btw, my own web app *will* reject input and / or normalize it
(whenever it is done, with which I mean: I first have to sort out some
issues with the database ...).

Greetings
-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Dienstag, den 16.12.2008, 16:00 +0100 schrieb Giovanni Campagna:
> In a forum you usually write BBCode (or similar), that is server-side
> parsed with the same hacks as the HTML5 parser, while in other context
> it is definitely more powerful to write directly HTML
But people who choose to write HTML should know some basic rules, or
shouldn't they ⸮

> Secondly, this:
> Click on my icon  src=myicon.png>
> 
> is valid HTML although not valid XHTML. Do you mean this with "messing
> up your code"?
Yes and yes. The WYSIWYG editor should know if it outputs XHTML or HTML.
Software usually has a switch for that.

> Have you got any ideas? 
Pointing out the smallest invalid subtree, along with a valid suggestion
for common errors (like not closing self-closing elements like ,
) would be a start:

It appears that you have neglected to close an  element at line 1
('bar'). How would you like Blogware to correct that ?

( ) Remove element.
( ) Self-close element.
(x) Close element immediately before parsing error (recommended).

[ Submit ]

> In any case, it is not allowable for companies to have their site down
> because of an user, even for just few minutes (if your lucky and find
> bug immediately)
I don't know why that should happen when using software that doesn't let
malformed (or otherwise unexpected) input slip through.

-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Tab Atkins Jr.]

On Mon, Dec 15, 2008 at 8:36 PM, Garrett Smith  wrote:
> On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr.  wrote:
>>> You're not Nicholas. We don't know if that is what Nicholas expects
>>> his HTML to do or if he is expecting something else. In absence of an
>>> example, I can't do much more than guess. I cannot expect your
>>> assumptions to be correct.
>>
>> Well, of course, but you sent the message to the entire group, so you
>> should be ready for answers from the whole group.  ^_^
>>
>>> You've not stated how creating invalid HTML can "control scripts".
>>> Having an interest in scripting, I would like to know how this works.
>>
>> Dude, come on.  You're trying to poison the dialogue here.  The point
>
> Instead of a complaining about my intentions, why don't you post an
> example that shows the problem (demonstrate need), how the problem is
> overcome (the invalid HTML solution), and what browsers actually do?

Sorry, I thought I was demonstrating it, but I guess I was being too
general.  An example I know of off the top of my head is the jQuery
Validation plugin[1].  If you can uniquely identify the elements in
your form (either through #id or other structural means) and can place
scripts (not always possible for end-users of a CMS application or
something), you can tell the plugin exactly how to validate each form
element when you first invoke it, through the script.

If either of these are false, though, you can instead place the
attributes on the element itself, and the script will read them off
while it's executing.  Many of the common ones can be easily and
usefully embedded in @class (giving an element a class of required,
frex, can also help with styling), but using the more complex
validation routines in @class requires you to embed JSON, which is a
horrible hack (as the parser doesn't recognize this and just tokenizes
it as multiple oddly named classes).  The script reads the entire
class attribute as a string and parses this effectively, but it can
have unintended consequences.

Instead, you can embed these more complex routines in custom
attributes.  jQuery has a plugin that allows easy access to these in a
cross-browser way (the Metadata plugin[2]).  Doing this allows you to
embed complex validation instructions on the elements themselves in an
easily human-readable and human-writable format, with an absolute
minimum of side-effects (generally, *no* side effects).

> I've seen code that has invalid attributes. These attributes won't
> always have the same effect as the author wanted them to. Not all
> authors expect the same thing from their invalid HTML.
>
> Recent c.l.js discussions have included examples of page author using
> a named element where that element does not support the name
> attribute, e.g. . The author had expected the
> element to be included with getElementsByName, but it wasn't. (not the
> first time someone has expected nonstandard behavior from an
> attribute). I've seen other uses of invalid HTML that did what the
> author wanted to in most cases.

This is (one reason) why I objected to using the blanket term "invalid
HTML", because it covers far more than what we're talking about here.
*I*, and Nicholas I'm sure, are referring solely to using *custom*
attributes.  In this example, you're talking about hacking an existing
attribute, and being surprised at the outcome.  (I find it likely that
the author was trying to use @name as a replacement for @class, hoping
to lean on the already-implemented getElementsByName function rather
than rolling his own getElementByClass).

>> As to how custom attributes can help control scripts, look into any
>> decent javascript plugin.  Many of them utilize some form of metadata
>
> What is a javascript plugin?
>
> The  element is designed for associating data with a plugin,
> such as a swf movie. Is this an allusion?

I apologize; I thought the term was widespread enough.  When using
things like the jQuery library, additional scripts built on top of it
are termed 'plugins'.


In general, though, the case for custom attributes is identical to the
case for JS expando attributes, which *have* been around for a long
time.  It can be very useful for a script to store arbitrary data on
an element, and the simplest way to do this in many cases is by
creating a new expando attribute.  Custom attributes is nothing more
than a way to embed this information in the static HTML as well, so
that it can be authored and carried around independently of the
script, or provide good 'initial values' to the script.

And again, as stated previously, this discussion *has* already been
settled.  We have the data-* attributes as an officially blessed way
to provide custom attributes on HTML, and as a recommended way to add
expando attributes via JS.  What I'm talking about is only 'invalid
HTML' in HTML4 - it's perfectly valid html5 now.

1: http://bassistance.de/jquery-plugins/jquery-plugin-validation/
2: http://dev.jquery.com/view/trunk/plugins/metadata

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/16 Nils Dagsson Moskopp <
nils-dagsson-mosk...@dieweltistgarnichtso.net>

> Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna:
>
> > (The same behaviour can be achieved also with a @namespace rule,
> > putting non-standard attributes in an application-specific namespace)
>
> Since data attributes do not exist as of yet, I believe people would use
> XML for namespaces, so I somehow don't see your problem.
>
> 1) data attributes are not standarized and the "dataset" DOMStringMap is
not present, but if you try using them with domCore interfaces they should
work (i haven't tested though)
2) XML serialization is much more difficlut to implement than old HTML, and,
as i said before, in many cases it is not implementable at all: probably a
company which hosts user-generated content such as blogs or forums won't
like that no browser can display his pages because someone wrote invalid
html
even the most experienced can mis-type code, and in that case the only way
to solve is to manually edit source using a plain text editor, which is not
possible with user-generated content
3) the "dataset" DOMStringMap is a quite useful way to enumerate attributes
explicitly marked as "application data"

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna:

> (The same behaviour can be achieved also with a @namespace rule,
> putting non-standard attributes in an application-specific namespace)

Since data attributes do not exist as of yet, I believe people would use
XML for namespaces, so I somehow don't see your problem.

-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna:
> Browser assume that author knows XML because he's put an application/*
> +xml mime type.
> On the other hand, this assumption cannot be done for blogger, who
> aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs
> (they're not expected to know about what or w3c either)
Then they shouldn't write XHTML in the first place ... there *are* some
good autoformatters which handle stuff for you (think: newline -> ,
two newlines -> aragraph). Also, WYSIWYG editors should *not* gave
you the oppontuniy to mess up your code.

> > Could not save you post, invalid XML markup (Mismatched end tag,
> expecting , found )
> > See W3C XML1.1 specification (link to  XML spec) for further
> information about this.
> Or just "Not well-formed (attribute values must be encoded in double
> quotes)"
The current error messages are crap, that is totally right. They could
certainly be more user-friendly.

> You have no page, thus no way to edit!
The admin interface should be always well-formed, having the offending
portion in a  (or similar) for easy editing and an 
for viewing.

-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/16 Nils Dagsson Moskopp <
nils-dagsson-mosk...@dieweltistgarnichtso.net>

> Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna:
> > Browser assume that author knows XML because he's put an application/*
> > +xml mime type.
> > On the other hand, this assumption cannot be done for blogger, who
> > aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs
> > (they're not expected to know about what or w3c either)
> Then they shouldn't write XHTML in the first place ... there *are* some
> good autoformatters which handle stuff for you (think: newline -> ,
> two newlines -> aragraph). Also, WYSIWYG editors should *not* gave
> you the oppontuniy to mess up your code.

In a forum you usually write BBCode (or similar), that is server-side parsed
with the same hacks as the HTML5 parser, while in other context it is
definitely more powerful to write directly HTML
Secondly, this:
Click on my icon 
is valid HTML although not valid XHTML. Do you mean this with "messing up
your code"?

>
> > > Could not save you post, invalid XML markup (Mismatched end tag,
> > expecting , found )
> > > See W3C XML1.1 specification (link to  XML spec) for further
> > information about this.
> > Or just "Not well-formed (attribute values must be encoded in double
> > quotes)"
> The current error messages are crap, that is totally right. They could
> certainly be more user-friendly.

Have you got any ideas?


> > You have no page, thus no way to edit!
> The admin interface should be always well-formed, having the offending
> portion in a  (or similar) for easy editing and an 
> for viewing.
>
In any case, it is not allowable for companies to have their site down
because of an user, even for just few minutes (if your lucky and find bug
immediately)

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/16 Nils Dagsson Moskopp <
nils-dagsson-mosk...@dieweltistgarnichtso.net>

> It is not hard to reject input if its not well-formed. If browsers can
> do it, why shouldn't web apps be able to ?
>
Browser assume that author knows XML because he's put an application/*+xml
mime type.
On the other hand, this assumption cannot be done for blogger, who aren't
expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs (they're not
expected to know about what or w3c either)


> As I said, invalid input should be rejected in the first place. When I
> write a blog post, I usually catch errors like this when I click on the
> "preview" button and its all yellow.

two way to implement:
- server-side checking: every input from user is checked to be well-formed
xml
Can you imagine what a blogger can think when the web page reports:
> Could not save you post, invalid XML markup (Mismatched end tag, expecting
, found )
> See W3C XML1.1 specification (link to  XML spec) for further information
about this.
Or just "Not well-formed (attribute values must be encoded in double
quotes)"
It is difficult to understand and debug for an experienced web designer,
guess for a casual poster
- client-side checking (the all-yellow page you mentioned)
The browser says "Not well formed" (this is what Firefox and Opera
generically say)
You know what it means and you open the source code. Then you find an
unencoded ampersand... And then?
You have no page, thus no way to edit!
Giovanni Campagna

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Dienstag, den 16.12.2008, 15:02 +0100 schrieb Giovanni Campagna:

> 2) XML serialization is much more difficlut to implement than old
> HTML, and, as i said before, in many cases it is not implementable at
> all: probably a company which hosts user-generated content such as
> blogs or forums won't like that no browser can display his pages
> because someone wrote invalid html
It is not hard to reject input if its not well-formed. If browsers can
do it, why shouldn't web apps be able to ?

> even the most experienced can mis-type code, and in that case the only
> way to solve is to manually edit source using a plain text editor,
> which is not possible with user-generated content
As I said, invalid input should be rejected in the first place. When I
write a blog post, I usually catch errors like this when I click on the
"preview" button and its all yellow.

-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
> Maybe so-called "invalid" HTML attributes are not the only solution,
> but in my opinion it is a simple way to embed metadata within any
> element.
What metadata are you talking about ? Microformats already exist.

> Personally I prefer the latter (XML) solution, but there are context
> where using XML serialization is not possibile (for example in user
> generated content) so there is a definite need for a SGML way to add
> custom attributes without conflicting with standards.
HTML5 is not derived from SGML anymore.


Greetings
-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/16 Nils Dagsson Moskopp <
nils-dagsson-mosk...@dieweltistgarnichtso.net>

> Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
> > Maybe so-called "invalid" HTML attributes are not the only solution,
> > but in my opinion it is a simple way to embed metadata within any
> > element.
> What metadata are you talking about ? Microformats already exist.


I'm talking of any data that is related semantically to element and should
not be printed to the user or interact with default browser behaviour. There
is an example in the HTML5 spec of an element representing a spaceship in a
browser game, with data- attributes to provide fire / armour values
Imagine the spaceship has class "spaceship", then i can write the following
css:
.spaceship:after {
display:block;
height: 10px;
width:  attr(data-attack,px);
background-color: red;
color: white;
text-align: center;
content: "Attack value " attr(data-attack,string);
}
.spaceship:after:after {
display:block;
height: 10px;
width:  attr(data-defence,px);
background-color: green;
color: white;
text-align: center;
content: "Defence value " attr(data-defence,string);
}
(The same behaviour can be achieved also with a @namespace rule, putting
non-standard attributes in an application-specific namespace)

>
> > Personally I prefer the latter (XML) solution, but there are context
> > where using XML serialization is not possibile (for example in user
> > generated content) so there is a definite need for a SGML way to add
> > custom attributes without conflicting with standards.
> HTML5 is not derived from SGML anymore.
>
My fault, I meant the HTML serialization of HTML5.
Giovanni Campagna

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

Maybe so-called "invalid" HTML attributes are not the only solution, but in
my opinion it is a simple way to embed metadata within any element.

Imagine that such markup is then passed to a web application through XHR. In
that case scripts aren't parsed and executed. In this case you have three
ways to attach a behaviour:

2) on-event standard attributes (but they not performant since they're
parsed every time the event fires and the cannot include chars like > or ",
they need to be escaped)
3) assigning a "class" and some metadata using "data-", then
getElementsByClassName and addEventListener

The same with CSS: you can use "style" for each element or "data-"
attributes queried by attr()

For what concerns browser support, these attributes are at all part of the
DOM tree, so I can pass their names to getAttribute and setAttribute, but
they don't get any special interface.

It's the same in the XML serialization with different application-specific
namespaces: they use only DOMAttr interface defined in DOM3Core and they're
not part of any infoset (not part of ID list or NAME list)

Personally I prefer the latter (XML) solution, but there are context where
using XML serialization is not possibile (for example in user generated
content) so there is a definite need for a SGML way to add custom attributes
without conflicting with standards.

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

I tried following this thread but I can't find what I would need to change 
in the spec to address the feedback so far. If this feedback relates to 
requests for the spec, please elaborate on exactly what it is that should 
change -- thanks!

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/16 Ian Hickson 

>
> I tried following this thread but I can't find what I would need to change
> in the spec to address the feedback so far. If this feedback relates to
> requests for the spec, please elaborate on exactly what it is that should

change -- thanks!

I thought later on this topic and i arrived to conclusion that we cannot
forbid or delete completely the HTML serialization, but there are no real
use cases for this in server generated web pages. Even in case of
user-generated content an application must parse it server-side prior to
publish, and in the worst case may use the spec's algorithm to build a
standard-compliant DOM tree, then serialize it producing valid XML code
(therefore an application can always provid valid XHTML)
In my opinion, we should allow content to be sent as text/html, but HTML
serialization and associated technologies (DOMDocument.write or
DOMElement.outerHTML) should be marked deprecate, since there are stricter
and more performant way to do same thing.
Giovanni Campagna

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Wed, 17 Dec 2008, Giovanni Campagna wrote:
> 
> I thought later on this topic and i arrived to conclusion that we cannot 
> forbid or delete completely the HTML serialization, but there are no 
> real use cases for this in server generated web pages. Even in case of 
> user-generated content an application must parse it server-side prior to 
> publish, and in the worst case may use the spec's algorithm to build a 
> standard-compliant DOM tree, then serialize it producing valid XML code 
> (therefore an application can always provid valid XHTML) In my opinion, 
> we should allow content to be sent as text/html, but HTML serialization 
> and associated technologies (DOMDocument.write or DOMElement.outerHTML) 
> should be marked deprecate, since there are stricter and more performant 
> way to do same thing.

XML is neither more performant nor stricter than XML. The main differences 
are that XML has less user-friendly error recovery and supports arbitrary 
namespaces. Authors have clearly indicated that this is not compelling. 
Deprecating HTML thus seems like vain effort. (We already tried over the 
past few years with XHTML 1.x, and it didn't work.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/17 Ian Hickson 
>
> XML is neither more performant nor stricter than XML. The main differences
> are that XML has less user-friendly error recovery and supports arbitrary
> namespaces. Authors have clearly indicated that this is not compelling.
> Deprecating HTML thus seems like vain effort. (We already tried over the
> past few years with XHTML 1.x, and it didn't work.)
>
> I don't write browser code, honestly, but I think that XML parser don't
need to check for attribute types (they're all quoted strings), don't check
for element type (whether there can or must be closing tag), don't check for
insertion modes, just parses the input completely any semantic or particular
behaviour associated with any tag. Then, when the DOMElement or DOMAttr or
DOM-whatever are built, they get the appropriate interface (eg. HTMLElement)
depending on the namespace.

I think that the latter algorithm can be faster, but I actually haven't got
any benchmark (I cannot have, since no browser implements completely HTML5
parse algorithm yet).

Secondly, stricter to me means: every warning is an error. Look in the
following code:
some text
When the HTML parser find char 'd', i can imagine it expects char 'p' (as in
) and fallback to "quirk mode" otherwise, although no assertion are made
in the official HTML spec.
When parsing as XML, though, the parser can simply get the char: is it a
'p'? then go forward, else stop parsing
no quirks, no trying to guess author intentions

what about some textsome more text?
is it this: some textsome more text
or either this: some textsome more text

And most of time strict checking means less errors caused by distraction
(misspelling of an end tag, missing '/' when self-closing elements not
always selfclosing, etc.)

Lastly, you said that deprecating HTML is vain. Well, IMO, if you deprecate
it now, maybe this year, or next year, or even the year after, nothing will
move. But (according to WHATWG Wiki) HTML spec will be ready in 2020.

Do you think that in 12 years everybody will just ignore the string "HTML is
deprecated and should no longer be used"?

By the way, XHTML1.0 / 1.1 said nothing about HTML4, they were independent
specifications.

Giovanni Campagna

Re: [whatwg] Thoughts on HTML 5

[Ian Hickson]

On Wed, 17 Dec 2008, Giovanni Campagna wrote:
>
> I don't write browser code, honestly, but I think that XML parser don't 
> need to check for attribute types (they're all quoted strings),

XML parsers still have to check for quotes (" vs '), which takes no less 
time than HTML's checking for quotes (" vs ' vs nothing).


> don't check for element type (whether there can or must be closing tag), 

This doesn't cost any time in HTML either, since the tokeniser doesn't 
need to worry about what tags have end tags, the tree construction side 
just drops unexpected end tags on the floor.


> don't check for insertion modes

Having an insertion mode isn't particularly a performance cost. (It 
affects code footprint, but that's about it.)


> just parses the input completely any semantic or particular behaviour 
> associated with any tag. Then, when the DOMElement or DOMAttr or 
> DOM-whatever are built, they get the appropriate interface (eg. 
> HTMLElement) depending on the namespace.

That's the same as HTML.


> I think that the latter algorithm can be faster, but I actually haven't 
> got any benchmark (I cannot have, since no browser implements completely 
> HTML5 parse algorithm yet).

There are a number of HTML5 parser implementations, and data suggests that 
there is no particular performance gain.


> Secondly, stricter to me means: every warning is an error. Look in the
> following code:
> some text
> When the HTML parser find char 'd', i can imagine it expects char 'p' (as in
> ) and fallback to "quirk mode" otherwise, although no assertion are made
> in the official HTML spec.

Not at all, the  is completely optional in HTML, so that's not a 
problem. Also, it doesn't switch to quirks mode. The HTML5 spec defines 
how to handle these cases in excruciating detail.


> When parsing as XML, though, the parser can simply get the char: is it a
> 'p'? then go forward, else stop parsing
> no quirks, no trying to guess author intentions

There's no guessing in HTML either; all input streams have very specific 
and required results.


> what about some textsome more text?
> is it this: some textsome more text

Both of those are valid.

> or either this: some textsome more text

All three of these have very well-defined results. There's no ambiguity or 
guessing involved.


> And most of time strict checking means less errors caused by distraction 
> (misspelling of an end tag, missing '/' when self-closing elements not 
> always selfclosing, etc.)

Validating code is certainly an important QA point, but once you've 
shipped code, the presence of an error is not helpful to the end user. 
Often errors in XML files weren't present when the file was created, but 
appear later when new text is merged in automatically.


> Lastly, you said that deprecating HTML is vain. Well, IMO, if you 
> deprecate it now, maybe this year, or next year, or even the year after, 
> nothing will move. But (according to WHATWG Wiki) HTML spec will be 
> ready in 2020.
> 
> Do you think that in 12 years everybody will just ignore the string 
> "HTML is deprecated and should no longer be used"?

Well, they've ignored it for the past 7 years, so why would they change?


> By the way, XHTML1.0 / 1.1 said nothing about HTML4, they were 
> independent specifications.

They were positioned as replacements.


Anyway, it isn't clear that we would _want_ to deprecate HTML, even if we 
had any real choice in the matter.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5

[Garrett Smith]

On Tue, Dec 16, 2008 at 5:14 AM, Giovanni Campagna
 wrote:
> Maybe so-called "invalid" HTML attributes are not the only solution, but in
> my opinion it is a simple way to embed metadata within any element.
>
> Imagine that such markup is then passed to a web application through XHR. In
> that case scripts aren't parsed and executed. In this case you have three
> ways to attach a behaviour:
>
> 2) on-event standard attributes (but they not performant since they're
> parsed every time the event fires and the cannot include chars like > or ",
> they need to be escaped)
> 3) assigning a "class" and some metadata using "data-", then
> getElementsByClassName and addEventListener
>

What is the first way?

I usually prefer to use bubbling.

If the callback has an event target that it is interested in, it can
deal with it at that time.

Garrett

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/17 Ian Hickson 

>
> This doesn't cost any time in HTML either, since the tokeniser doesn't
> need to worry about what tags have end tags, the tree construction side
> just drops unexpected end tags on the floor.
>
I don't think authors expect tags to disappear.

>
> > don't check for insertion modes
>
> Having an insertion mode isn't particularly a performance cost. (It
> affects code footprint, but that's about it.)
>
1) it needs more code (one x insertion mode): more code is always less
performance, even if it is just to load a bigger executable
2) it needs code to  select the insertion mode for the next element (when
the spec says  to reset the insertion mode): in the worst case it has to
compare nodeName 18 times
> That's the same as HTML.
No it is not. HTML defines special beaviour for the following elements:
 address, area, article, aside, base, basefont, bgsound, blockquote, body,
br, center, col, colgroup, command, datagrid, dd, details, dialog, dir, div,
dl, dt, embed, eventsource fieldset, figure, footer, form, frame, frameset,
h1, h2, h3, h4, h5, h6, head, header, hr, iframe, img, input, isindex, li,
link, listing, menu, meta, nav, noembed, noframes, noscript, ol, p, param,
plaintext, pre, script, section, select, spacer, style, tbody, textarea,
tfoot, thead, title, tr, ul, and wbr.
I think they're quite too many to say that it is like XML

> There are a number of HTML5 parser implementations, and data suggests that
> there is no particular performance gain.
There are no actual HTML5 parser implementation, only HTML4 compatible with
new syntax. (are you sure that closed source browsers really do what is
written in the specification?)

> There's no guessing in HTML either; all input streams have very specific
> and required results.
Actually, there's nothing that really says that some textsome
more text is more correct than some textsome more
text

Just when writing the specification you guess that the first possibility is
what auctor thought. You are guessing, not the browser.

> Validating code is certainly an important QA point, but once you've
> shipped code, the presence of an error is not helpful to the end user.
> Often errors in XML files weren't present when the file was created, but
> appear later when new text is merged in automatically.

As Nils pointed, it is an error itself to have any content to be
automatically merged inside a stream. It is like opening a random file,
executing it and expecting no errors. Every input, even from the most
trustworthy source, must be parsed for errors and then checked after
publishing.
And if an end user finds an error, he probably will report it to the owner
of the web site, who in turn will report it (quite angrily) to web designer.
Something like: "What on earth are you doing in front of the coffe machine?
I don't pay you to rest! Fix that website immediately!
> Well, they've ignored it for the past 7 years, so why would they change?
Nobody said to user that he was browsing a deprecate web site. If something
like IE7 information bar (ie. a non modal bar, disactivable and not annoying
the user, but immediately visible) could appear in a  web site sent with
 text/html,  I think companies won't like their site tagged as "deprecate"
and port them to application/xhtml+xml in no time (do you imagine what
"deprecate" can mean on news web site?)
And don't forget that the most common browser was IE6, not very standard
oriented...
> Anyway, it isn't clear that we would _want_ to deprecate HTML, even if we
> had any real choice in the matter.

I'm not sure if I understood your sentence (sorry, English is not my mother
language). Anyway, you just have to put an "authoring requirement" for
text/html

1) user agent will just ignore it and implement the HTML algorithm (we don't
want to "break the web", using Microsoft terms)
2) standard-oriented authors will convert their sites to
application/xhtml+xml (if they didn't before)
3) other authors will keep their tag soup (and get their sites
yellow-barred)
4) company owners will make their decision between 2 and 3

Gradually, n° 3 will disappear, because there's no actual needing for HTML.

@ Garret:
originally I wrote XBL2, then I deleted it since it was not pertinent (and
went in opposite direction as my opinion), but i forgot to edit list number.

Secondly, what do you mean with bubbling? Ok, I can put an event handler on
what I need on, say, , but then how can I execute the proper handler?
I must retrieve it, either attaching it to the DOM node (but I don't advice
it, it is not interoperable) or maintaing an hash map with class names /
function pointers and solve it.

Actually, there is no performant and clean solution, just few hacks.

Re: [whatwg] Thoughts on HTML 5

[Benjamin Hawkes-Lewis]

Giovanni Campagna wrote:

2008/12/17 Ian Hickson 


This doesn't cost any time in HTML either, since the tokeniser doesn't
need to worry about what tags have end tags, the tree construction side
just drops unexpected end tags on the floor.

I don't think authors expect tags to disappear.


Perhaps (got any actual evidence about author expectations in this 
case?), but that's not a problem for tokenizer performance. You're 
"shifting the goalposts".


Anyway, if we're talking authorial expectations, ordinary authors don't 
expect


http://example.com?foobar&baz";>

to be an unrecoverable error, but it is in XHTML.

It's not like either of these syntaxes make sense to ordinary people or 
were even intended to do so. The original authoring model for HTML was 
supposed to be "paragraph" and "anchor", mediated by some sort of 
vaguely WYSIWYG type editor, not angle-bracketed tags.



 > don't check for insertion modes

Having an insertion mode isn't particularly a performance cost. (It
affects code footprint, but that's about it.)

1) it needs more code (one x insertion mode): more code is always less 
performance, even if it is just to load a bigger executable
2) it needs code to  select the insertion mode for the next element 
(when the spec says  to reset the insertion mode): in the worst case it 
has to compare nodeName 18 times

 > That's the same as HTML.
No it is not. HTML defines special beaviour for the following elements: 
 address, area, article, aside, base, basefont, bgsound, blockquote, 
body, br, center, col, colgroup, command, datagrid, dd, details, dialog, 
dir, div, dl, dt, embed, eventsource fieldset, figure, footer, form, 
frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hr, iframe, img, 
input, isindex, li, link, listing, menu, meta, nav, noembed, noframes, 
noscript, ol, p, param, plaintext, pre, script, section, select, spacer, 
style, tbody, textarea, tfoot, thead, title, tr, ul, and wbr.

I think they're quite too many to say that it is like XML

 > There are a number of HTML5 parser implementations, and data suggests 
that

 > there is no particular performance gain.
There are no actual HTML5 parser implementation, only HTML4 compatible 
with new syntax.


Ahem, there are several:

http://www.google.com/search?q=html5+parser


 > There's no guessing in HTML either; all input streams have very specific
 > and required results.
Actually, there's nothing that really says that some 
textsome more text is more correct than some 
textsome more text


Just when writing the specification you guess that the first possibility 
is what auctor thought. You are guessing, not the browser.


A conforming browser will interpret the markup as specified by the 
specification, so there is no difference.


Every input, even from the most 
trustworthy source, must be parsed for errors and then checked after 
publishing.


In practice, people find this very hard for XML and most web publishing 
systems (WordPress etc.) don't work like this even if they should.


Also, much of the web is ad-supported. The ads ecosystem is based around 
including markup from trusted sources. Those including the markup are 
generally not able to exert much control over the included markup, even 
when they are some of the biggest publishers on the web. Getting ads to 
have user-friendly HTML (e.g. alt attributes for image links) is nigh 
impossible; trying to get conforming HTML is a wet dream; and trying to 
get ads in valid XML is a likely to be a complete non-starter. Why would 
an ad creator bother, when they could choose a different partner and use 
their old text/html ads?


And if an end user finds an error, he probably will report it to the 
owner of the web site, who in turn will report it (quite angrily) to web 
designer. Something like: "What on earth are you doing in front of the 
coffe machine? I don't pay you to rest! Fix that website immediately!


"Probably" - got any empirical evidence for that? I don't usually report 
errors in websites I visit (even _I_ usually have other things to do 
with my time).


In any case, avoiding angry customers complaining because XML threw a 
fatal error that would have been handled gracefully in HTML is an 
infinitely stronger incentive for developers to keep using text/html 
than anything the spec might say on the matter, so this isn't a 
persuasive argument for switching to application/xhtml+xml.



 > Well, they've ignored it for the past 7 years, so why would they change?
Nobody said to user that he was browsing a deprecate web site. If 
something like IE7 information bar (ie. a non modal bar, disactivable 
and not annoying the user, but immediately visible) could appear in a 
 web site sent with  text/html,  I think companies won't like their site 
tagged as "deprecate" and port them to application/xhtml+xml in no time 
(do you imagine what "deprecate" can mean on news web site?)


Indeed, they would be upset. And they might even try porting i

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/18 Benjamin Hawkes-Lewis 

>
> Perhaps (got any actual evidence about author expectations in this case?),
> but that's not a problem for tokenizer performance. You're "shifting the
> goalposts".
>

My comment about tokenizer performance was later. By the way, author should
not expect that invalid markup work in any particular way (in the past they
did and wrote specific markup for specific implementation)


> Anyway, if we're talking authorial expectations, ordinary authors don't
> expect
>
> http://example.com?foobar&baz";>
>
> to be an unrecoverable error, but it is in XHTML.


authors didn't expect that example.com?foobar§ion=1 became
example.com?foobar§ion=1 but this happened in Netscape and IE quite long ago
if they got an error, at least they knew that it was not a correct syntax
and should have been avoided, since it could lead to different results in
different browsers
(it is not valid HTML, btw)

It's not like either of these syntaxes make sense to ordinary people or were
> even intended to do so. The original authoring model for HTML was supposed
> to be "paragraph" and "anchor", mediated by some sort of vaguely WYSIWYG
> type editor, not angle-bracketed tags.

If you don't like like less-than and greater-than (it is not Unicode angle
bracket actually), publish your work in PDF or DOC. HTML stays for HyperText
Markup Language. Markup (i.e. tags) can't be removed.

A conforming browser will interpret the markup as specified by the
> specification, so there is no difference.

Yes, the fact is that the specification itself "guesses" what an average
author thinks when it writes HTML

> In practice, people find this very hard for XML and most web publishing
> systems (WordPress etc.) don't work like this even if they should.

Why do SQL injections or buffer overrun attacks happen? Because applications
don't check for input. The same for XML: you check, you're sure nobody will
try to take your site down. You don't check, that's your fault.

> Also, much of the web is ad-supported. The ads ecosystem is based around
> including markup from trusted sources. Those including the markup are
> generally not able to exert much control over the included markup, even when
> they are some of the biggest publishers on the web. Getting ads to have
> user-friendly HTML (e.g. alt attributes for image links) is nigh impossible;
> trying to get conforming HTML is a wet dream; and trying to get ads in valid
> XML is a likely to be a complete non-starter. Why would an ad creator
> bother, when they could choose a different partner and use their old
> text/html ads?

If ad buyer refuses to buy a non-valid-XML ad, probably the ad creator will
rewrite them.

"Probably" - got any empirical evidence for that? I don't usually report
> errors in websites I visit (even _I_ usually have other things to do with my
> time).

If any error prevents someone from correctly browsing that page, he first
reports that to web owner, then to browser creator.


>  Indeed, they would be upset. And they might even try porting it. However,
> there's little incentive for browser makers to throw information bars over
> the majority of the existing web just to assuage your desire for people to
> switch to XML. In fact, there are disincentives for browser vendors to
> include such an information bar since:

1. Users will complain about error messages about sites that have always
> worked just fine. ("I'm switching back to IE8.")

2. Users will be trained to ignore error messages since sites work just fine
> even with a finger-wagging information bar slapped across the top, which is
> a security risk.

Even persuading browser vendors to include an indication of whether a
> website is valid or not has been a non-starter for every browser except iCab
> - and even iCab has dropped that indication in the latest version.

If an user complains about a warning (not error) indication, he can disable
it (but not security errrors). On the other hand, some user will complain
with the site creator, instead of with the browser creator.

Ian was effectively asking: "Why deprecate text/html?" You appear to be
> trying to answer: "How would we deprecate text/html?" which is a different
> question (and I've indicated some problems with your suggestion above).

Sorry, I didn't understand (it looked like "we want to deprecate html but we
don't have instruments", but it didn't make much sense).

Except on the ad-supported web…

1) use 
2) use 
3) use 
4) use 
5) use well-formed XHTML
6) use JS + DOM
Do you think it is enough?
Giovanni Campagna

Re: [whatwg] Thoughts on HTML 5

[Benjamin Hawkes-Lewis]

Giovanni Campagna wrote:
2008/12/18 Benjamin Hawkes-Lewis >



Perhaps (got any actual evidence about author expectations in this
case?), but that's not a problem for tokenizer performance. You're
"shifting the goalposts".

 
My comment about tokenizer performance was later. By the way, author 
should not expect that invalid markup work in any particular way (in the 
past they did and wrote specific markup for specific implementation)


Depends on the context of that expectation. Authors should expect 
HTML5-conforming parsers to handle invalid markup precisely as specified 
in the HTML5 specification. They should not expect legacy browsers to do 
the same, but probably will in practice.



Anyway, if we're talking authorial expectations, ordinary authors
don't expect

http://example.com?foobar&baz ">

to be an unrecoverable error, but it is in XHTML.

 
authors didn't expect that example.com?foobar§ion=1 
 became example.com?foobar 
§ion=1 but this happened in Netscape and IE 
quite long ago
if they got an error, at least they knew that it was not a correct 
syntax and should have been avoided, since it could lead to different 
results in different browsers

(it is not valid HTML, btw)


If the author ever saw the error, which would be dependent on a culture 
of bug reporting.



It's not like either of these syntaxes make sense to ordinary people
or were even intended to do so. The original authoring model for
HTML was supposed to be "paragraph" and "anchor", mediated by some
sort of vaguely WYSIWYG type editor, not angle-bracketed tags.

If you don't like like less-than and greater-than (it is not Unicode 
angle bracket actually), publish your work in PDF or DOC. 


Those have even worse syntaxes - and as with most HTML, they aren't 
typically written by hand.


HTML stays for 
HyperText Markup Language. Markup (i.e. tags) can't be removed.


Not sure what you're arguing here.

You're the one suggesting people move from one serialization (text/html) 
to another (XML) on the basis that one is easier to understand. I'm 
basically saying that XML is still so hard for ordinary people to 
understand that it's not obviously worth the pain of migration on 
ease-of-use grounds and that, in this context, its draconian 
error-handling acts as an incentive to drive people back to text/html. 
They don't understand that either, but at least it works (or at least, 
appears to).



A conforming browser will interpret the markup as specified by the
specification, so there is no difference.

Yes, the fact is that the specification itself "guesses" what an average 
author thinks when it writes HTML


Correct. Likewise for XHTML (guessing that the author meant paragraph 
when a "p" element is supplied and quotation when a "blockquote" element 
is supplied, for example).



In practice, people find this very hard for XML and most web
publishing systems (WordPress etc.) don't work like this even if
they should.

Why do SQL injections or buffer overrun attacks happen? Because 
applications don't check for input. The same for XML: you check, you're 
sure nobody will try to take your site down. You don't check, that's 
your fault.


Absolutely true; I'm personally a big fan of aggressive input validation 
for text/html.


Input validation is worth advocating on its own grounds, whether for 
HTML or XHTML.


It doesn't automatically follow from this that making end-users suffer 
because of input validation failures where error-recovery could be 
graceful is a good idea.



Also, much of the web is ad-supported. The ads ecosystem is based
around including markup from trusted sources. Those including the
markup are generally not able to exert much control over the
included markup, even when they are some of the biggest publishers
on the web. Getting ads to have user-friendly HTML (e.g. alt
attributes for image links) is nigh impossible; trying to get
conforming HTML is a wet dream; and trying to get ads in valid XML
is a likely to be a complete non-starter. Why would an ad creator
bother, when they could choose a different partner and use their old
text/html ads?

If ad buyer refuses to buy a non-valid-XML ad, probably the ad creator 
will rewrite them.


You're ignoring the fact that there is a competitive advantage in 
supporting text/html ads, because the most popular browser doesn't 
support application/xhtml+xml and because text/html has non-draconian 
error handling so end-users are more likely to see the ad.


You're best hope would be to identify a competitive advantage for a 
person buying advertising to show a application/xhtml+xml ad that would 
justify a higher risk of users not seeing the ad. Good luck with that. :)



"Probably" - got any empirical evidence for that? I don't usually
 

Re: [whatwg] Thoughts on HTML 5

[Philipp Kempgen]

Ian Hickson schrieb:

> Deprecating HTML thus seems like vain effort. (We already tried over the 
> past few years with XHTML 1.x, and it didn't work.)

I'd say it _did_ work.  :-)

   Philipp Kempgen

Re: [whatwg] Thoughts on HTML 5

[Nils Dagsson Moskopp]

Am Sonntag, den 21.12.2008, 17:54 +0100 schrieb Philipp Kempgen:
> Ian Hickson schrieb:
> 
> > Deprecating HTML thus seems like vain effort. (We already tried over the 
> > past few years with XHTML 1.x, and it didn't work.)
> 
> I'd say it _did_ work.  :-)
I'd say too: The worst abominations have disappeared (for new sites,
that is). the  element, for example, or frames through deprecating
them.

Fact: Deprecating stuff takes it out of (X)HTML-Books, Howtos like
Selfhtml warn against it, thus ensuring lesser use by novices. Does
anyone remember  ?


Cheers
-- 
Nils Dagsson Moskopp

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

Please Note: all the following is my personal humble opinion.

As I discovered lately, the main problem of HTML5 is its design oriented to
keep features that are distributed across browsers, that work or that are
simple way to solve big problem. Actually, they are a bunch of different
features somehow not integrated to the others.
Instead, programmer (please note, I use the word programmer, not author or
web designer) developing *new* application may more like a more structured
and logical organization, like XHTML modularization is.
HTML5 features, summed in big groups, are (in spec order):
1) common syntax for the most used datatypes.
2) additional DOM interfaces, which include HTMLElement - HTMLCollection -
HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList -
DOMStringMap
3) Elements and Content Models
4) Element types: metadata - structure - sectioning - grouping - text -
editing - embedding - table - forms - interactive - scripting elements
5) User agent requirements
6) User Interaction
7) Communication
8) HTML Syntax

Some of these features can be achieved without any of HTML5, for example
1) use XMLSchema datatypes
2) you don't need HTMLElement: markup insertion, attributes querying can be
done using DOM3Core (that in latest browser are even more performant as no
parser is involved), events are far better handled by DOM3Events, styling is
included by CSSOM
you don't need collection either: just use appropriate DOMNodeLists, while
for DOMStringMap you may use binding specific features (all Object are hash
maps in ECMAScript3): it works this way even in HTML5
3) use XHTML2, which is extensible because modularized
4) metadata is better handled by XHTML2 Meta Attributes module, which fully
integrates the RDF module in any elements;
structure, sectioning, grouping are the same;
text is very similar: you don't have time, but you can have Today as in HTML5 you have
Today; for progress and meter semantic you
can use role attribute (for styling you always use CSS); editing is the
same, but you have an attribute instead of an element, so you don't have the
issue that ins and del can contain everything, even a whole document (not
including );
embedding is much more powerful as any element can be replaced by embedded
content;
tables are the same (you don't have tables API; but you can still use
DOM3Core);
XForms are actually more powerful than WebForms2, since you divide
presentation from data from action (that is implemented declaratively);
interactive elements are not needed at all: details is better implemented as
it is now (ECMAScript3 + CSS3), datagrid is just a way to put data in a tree
model: use plain XML for that; command and a in XHTML2 implemented in any
element using href attribute; menu is mostly an ul with some style;
scripting uses XMLEvents and handler: it looks the same, but it is different
as it is more event oriented (scripts are not executed by default, they're
executed when some event fires)
8) HTML syntax: as I said before, use XML for that

There are instead features that are indeed very useful to develop a web
application, but are not achievable using other means that HTML5:
1) some way to interact with object (please note: object, not embed: object
is for plugins, embed for content) : actually this can be done using
something like cross document messaging, assuming that object creates a new
browsing context (it already does if the target is text/html or
application/xhtml+xml), but we need a specification for message syntax
2) the binding specific global scope (that is, what object are available in
all scopes, if binding supports this); this is normally the window object,
but scripts use certain features only on their own browsing context, so that
may be moved from that to global scope, removing the whole window object
from scope (for current javascript you can write
window.window.window.window.window... and get the same as nothing)
3) the Window object (which includes window name, window location, cross
document messaging, dialog windows)
4) Protocol and Content Handlers
5) Session and Local storage
6) Database storage
7) Drag and Drop
8) WebSockets

What I am asking now is so to "modularize HTML". copy those features into
separate, interoperable modules, removing legacy features (like
window.on-whatever event listener)
A copy of those will remain in HTML5, because browser implement them at the
moment, and the HTML5 goal is that all browser implement the same things in
the same ways

Instead, some web developers in the future will think that a modularized and
less redudant API is more usable, like I personally do, and switch to that,
without mixing with HTML5: actually, I guess what a Database API does inside
HTML.

Best regards,
Giovanni Campagna

Re: [whatwg] Thoughts on HTML 5

[Jorgen Horstink]

Hi Giovanni,

I haven't read your entire comment, but with your point eight will  
break backwards compatibility. As far as I know is HTML5 supposed to  
combine old and new. The problem with interfaces is that you can not  
simply change them. That's just a fact we have to deal with.


jorgen

On Dec 21, 2008, at 7:12 PM, Giovanni Campagna wrote:


Please Note: all the following is my personal humble opinion.

As I discovered lately, the main problem of HTML5 is its design  
oriented to keep features that are distributed across browsers, that  
work or that are simple way to solve big problem. Actually, they are  
a bunch of different features somehow not integrated to the others.
Instead, programmer (please note, I use the word programmer, not  
author or web designer) developing *new* application may more like a  
more structured and logical organization, like XHTML modularization  
is.

HTML5 features, summed in big groups, are (in spec order):
1) common syntax for the most used datatypes.
2) additional DOM interfaces, which include HTMLElement -  
HTMLCollection - HTMLFormsControlCollection - HTMLOptionsCollection  
- DOMTokenList - DOMStringMap

3) Elements and Content Models
4) Element types: metadata - structure - sectioning - grouping -  
text - editing - embedding - table - forms - interactive - scripting  
elements

5) User agent requirements
6) User Interaction
7) Communication
8) HTML Syntax

Some of these features can be achieved without any of HTML5, for  
example

1) use XMLSchema datatypes
2) you don't need HTMLElement: markup insertion, attributes querying  
can be done using DOM3Core (that in latest browser are even more  
performant as no parser is involved), events are far better handled  
by DOM3Events, styling is included by CSSOM
you don't need collection either: just use appropriate DOMNodeLists,  
while for DOMStringMap you may use binding specific features (all  
Object are hash maps in ECMAScript3): it works this way even in HTML5

3) use XHTML2, which is extensible because modularized
4) metadata is better handled by XHTML2 Meta Attributes module,  
which fully integrates the RDF module in any elements;

structure, sectioning, grouping are the same;
text is very similar: you don't have time, but you can have datatype="xsd:date" content="2008-12-21">Today as in HTML5  
you have Today; for progress and  
meter semantic you can use role attribute (for styling you always  
use CSS); editing is the same, but you have an attribute instead of  
an element, so you don't have the issue that ins and del can contain  
everything, even a whole document (not including );
embedding is much more powerful as any element can be replaced by  
embedded content;
tables are the same (you don't have tables API; but you can still  
use DOM3Core);
XForms are actually more powerful than WebForms2, since you divide  
presentation from data from action (that is implemented  
declaratively);
interactive elements are not needed at all: details is better  
implemented as it is now (ECMAScript3 + CSS3), datagrid is just a  
way to put data in a tree model: use plain XML for that; command and  
a in XHTML2 implemented in any element using href attribute; menu is  
mostly an ul with some style;
scripting uses XMLEvents and handler: it looks the same, but it is  
different as it is more event oriented (scripts are not executed by  
default, they're executed when some event fires)

8) HTML syntax: as I said before, use XML for that

There are instead features that are indeed very useful to develop a  
web application, but are not achievable using other means that HTML5:
1) some way to interact with object (please note: object, not embed:  
object is for plugins, embed for content) : actually this can be  
done using something like cross document messaging, assuming that  
object creates a new browsing context (it already does if the target  
is text/html or application/xhtml+xml), but we need a specification  
for message syntax
2) the binding specific global scope (that is, what object are  
available in all scopes, if binding supports this); this is normally  
the window object, but scripts use certain features only on their  
own browsing context, so that may be moved from that to global  
scope, removing the whole window object from scope (for current  
javascript you can write window.window.window.window.window... and  
get the same as nothing)
3) the Window object (which includes window name, window location,  
cross document messaging, dialog windows)

4) Protocol and Content Handlers
5) Session and Local storage
6) Database storage
7) Drag and Drop
8) WebSockets

What I am asking now is so to "modularize HTML". copy those features  
into separate, interoperable modules, removing legacy features (like  
window.on-whatever event listener)
A copy of those will remain in HTML5, because browser implement them  
at the moment, and the HTML5 goal is that all browser implement the  
same things in the same ways

Re: [whatwg] Thoughts on HTML 5

[Benjamin Hawkes-Lewis]

On 21/12/08 17:22, Nils Dagsson Moskopp wrote:

Am Sonntag, den 21.12.2008, 17:54 +0100 schrieb Philipp Kempgen:

Ian Hickson schrieb:


Deprecating HTML thus seems like vain effort. (We already tried over the
past few years with XHTML 1.x, and it didn't work.)

I'd say it _did_ work.  :-)

I'd say too: The worst abominations have disappeared (for new sites,
that is). the  element, for example, or frames through deprecating
them.


You're assuming that's an indication of the power of specifications 
rather than of actual advantages to using CSS or avoiding frames.


What mostly failed, and which Hixie is referring to, was the attempt to 
move the web from a tag soup (text/html) basis to an XML 
(application/xhtml+xml) basis. Perhaps that's because the advantages of 
the later were not persuasive. As I've argued elsewhere in the thread, 
there's money in staying with text/html.



Does anyone remember  ?


That's a bad example. MARQUEE was never standardized in a specification, 
so it was never possible to deprecate it.


--
Benjamin Hawkes-Lewis

Re: [whatwg] Thoughts on HTML 5

[Garrett Smith]

On Sun, Dec 21, 2008 at 10:12 AM, Giovanni Campagna
 wrote:
> Please Note: all the following is my personal humble opinion.

> parser is involved), events are far better handled by DOM3Events, styling is
> included by CSSOM

Styling is done in css.

I don't have time to go into the all the problems with CSSOM here.
Shortcomings of the CSSOM 'views' module were discussed on www-style.
'VIews' is not the only CSSOM module that has problems.

> you don't need collection either: just use appropriate DOMNodeLists, while
> for DOMStringMap you may use binding specific features (all Object are hash
> maps in ECMAScript3): it works this way even in HTML5

Where are you getting this information?


> but scripts use certain features only on their own browsing context, so that
> may be moved from that to global scope, removing the whole window object
> from scope (for current javascript you can write
> window.window.window.window.window... and get the same as nothing)

The closest definition to 'nothing' would be the value undefined. I do
not know of a browser where - window.window.window === undefined is
true by default. I get window.

A relevant example would be useful.

The closes thing we got to an example of invalid html is TJ post about
jquery validation plugin. If you click throuh, there is an demo using
a minlength custom attribute. The attribute may have the effect the
author wanted it to have in a set of browses he is concerned about.
That "effect" and the "set of browsers" could be more clearly
demonstrated in an example that shows only that, as well as edge cases
where results may vary.

If you can't define clearly what can be reasonably expected of a piece
of (invalid) code, then nothing can be reasonably expected of it. It's
not a good to write code that can't have an expected outcome.

> Best regards,
> Giovanni Campagna
>

Re: [whatwg] Thoughts on HTML 5

[Giovanni Campagna]

2008/12/21 Garrett Smith 

>
> Styling is done in css.


Dynamic styling is currently done with the style property of HTMLElement.
This is currently implemented in DOM2HTML and HTML5, but I once read they're
going to write a separate CSS-Object Model, whose spec is not ready yet, but
it is mentioned in the CSS current work.

I don't have time to go into the all the problems with CSSOM here.
> Shortcomings of the CSSOM 'views' module were discussed on www-style.
> 'VIews' is not the only CSSOM module that has problems.
>
Most of CSS is already implemented (like HTML, they're just standarizing
what browser already do)


> > you don't need collection either: just use appropriate DOMNodeLists,
> while
> > for DOMStringMap you may use binding specific features (all Object are
> hash
> > maps in ECMAScript3): it works this way even in HTML5
>
> Where are you getting this information?
>
What information?
a) DOMNodeList are collection of ordered Nodes --> see DOM3Core for
definition - if you want only Element Nodes see the Element Traversal
specification by the WebApps WG
b) ECMAScript Object are implemented as associative arrays (hash map /
binary tree) --> see Mozilla Developer Center: it is only about Firefox, but
I think all browser behave like this since they must reference arbitrary
properties that are not known at compile time (if they compile)
c) DOMStringMap is defined to be like ECMAScript Object --> look at its IDL:
it has no members, no properties, no methods

> but scripts use certain features only on their own browsing context, so
> that
> > may be moved from that to global scope, removing the whole window object
> > from scope (for current javascript you can write
> > window.window.window.window.window... and get the same as nothing)
>
The closest definition to 'nothing' would be the value undefined. I do
> not know of a browser where - window.window.window === undefined is
> true by default. I get window.


a) undefined != undefined is true in ECMAScript
b) i didn't mean undefined, i mean literally nothing, eg this script
window.window.window.window.window.window.window.alert("hello, world");
is exactly the same as
alert("hello, world");


> The closes thing we got to an example of invalid html is TJ post about
> jquery validation plugin. If you click throuh, there is an demo using
> a minlength custom attribute. The attribute may have the effect the
> author wanted it to have in a set of browses he is concerned about.
> That "effect" and the "set of browsers" could be more clearly
> demonstrated in an example that shows only that, as well as edge cases
> where results may vary.

I don't see your point...


> If you can't define clearly what can be reasonably expected of a piece
> of (invalid) code, then nothing can be reasonably expected of it. It's
> not a good to write code that can't have an expected outcome.
>
HTML5 is here to define what browser must and must not do with de-facto
standards (called DOM Level 0, but also features that once were
browser-specific like embed)
Instead what I'm asking is only for the developer point of view.


Giovanni

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ernest Cline]

-Original Message-
>From: Ian Hickson <[EMAIL PROTECTED]>
>Sent: May 13, 2008 6:09 PM
>To: Paweł Stradomski <[EMAIL PROTECTED]>
>Cc: whatwg@lists.whatwg.org
>Subject: Re: [whatwg] Thoughts on HTML 5
>
>On Tue, 13 May 2008, Paweł Stradomski wrote:
>> W liście Ian Hickson z dnia wtorek 13 maja 2008:
>> > > * I understand the concept of the  element but it's named
>> > > completely wrong. The point is to markup a conversation between two or
>> > > more parties. The problem is that the word "dialog", when in used in
>> > > user interfaces, refers to small windows that can be interacted with.
>> > > When I first read about this element, I assumed it was a way to indicate
>> > > that part of the page is a dialog window outside of the normal flow of
>> > > the document (which I thought was cool). After reading the rest, I was
>> > > disappointed to find out that wasn't the intent. I'd rename this element
>> > > as  or  to avoid such misunderstandings.
>> >
>> > I agree that the name is suboptimal but those names are worse (they're 
>> > too long, and they're overly specific). I'm not sure what to do about 
>> > this.
>> 
>> Perhaps  ? Short and simple, although not exactly equal in meaning 
>> to .
>
>That's probably the best suggestion so far, but I'm still not convinced 
>it's really much better than . I think it has at least as many 
>other interpretations (e.g. what we call a "talk" over here is really a 
>slide show).
>

The only synonym of dialog that is anywhere near as general seems to be 
.  The other possibility is  since the computing uses 
that cause confusion seem to have standardized on the shorter spelling.

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ian Hickson]

On Tue, 13 May 2008, Ernest Cline wrote:
> 
> The only synonym of dialog that is anywhere near as general seems to be 
> .

I dunno, that just sounds so formal.

I agree that  isn't perfect and could be (and has been) confused 
with dialog boxes, but I'm not convinced it's not the best name for the 
job anyway.


> The other possibility is  since the computing uses that cause 
> confusion seem to have standardized on the shorter spelling.

Experience with language="" on 

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ernest Cline]

-Original Message-
>From: Ian Hickson <[EMAIL PROTECTED]>
>Sent: May 13, 2008 7:20 PM
>To: Ernest Cline <[EMAIL PROTECTED]>
>Cc: whatwg@lists.whatwg.org, Paweł Stradomski <[EMAIL PROTECTED]>
>Subject: Re: [whatwg] Thoughts on HTML 5 - dialog
>
>On Tue, 13 May 2008, Ernest Cline wrote:
>> 
>> The only synonym of dialog that is anywhere near as general seems to be 
>> .
>
>I dunno, that just sounds so formal.
>
>I agree that  isn't perfect and could be (and has been) confused 
>with dialog boxes, but I'm not convinced it's not the best name for the 
>job anyway.

I agree that the word "discourse" is more formal than "dialog", but it does 
cover both formal and informal speech unlike some other thesaurus inspired 
possibilities such as "colloquy" or "chat".  It does have the advantage over 
dialog of avoiding the spelling issue and the computer term issue.  If those 
issues end up being judged sufficient to make  undesirable, then 
 seems to me to be the best alternative available among English 
words.  Of course, if words were abandoned altogether  would also be a 
possibility.

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ian Hickson]

On Tue, 13 May 2008, Ernest Cline wrote:
> 
> I agree that the word "discourse" is more formal than "dialog", but it 
> does cover both formal and informal speech unlike some other thesaurus 
> inspired possibilities such as "colloquy" or "chat".

Sure, I'm just reluctanct to use an element name that is too formal, as 
(for better or worse) that makes the language sound stilted.


> It does have the advantage over dialog of avoiding the spelling issue 
> and the computer term issue.  If those issues end up being judged 
> sufficient to make  undesirable, then  seems to me 
> to be the best alternative available among English words.  Of course, if 
> words were abandoned altogether  would also be a possibility.

 is probably too short for an element that won't be used that much.

Unless we get more evidence that the confusion with dialog boxes is a real 
blocker to adoption, I'm going to assume that  is our best option.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ernest Cline]

-Original Message-
>From: Ian Hickson <[EMAIL PROTECTED]>
>Sent: May 13, 2008 8:08 PM
>
>Unless we get more evidence that the confusion with dialog boxes is a real 
>blocker to adoption, I'm going to assume that  is our best option.

Is there any reasonable chance an element for a dialog box might end up being 
added to XForms?  (There is a proposal mentioned on the XForms wiki [1] for a 
possible dialog element for XForms 2.0, but I have no idea how much of a chance 
that proposal has as opposed to extending the message element.) I know that 
XHTML 5 + XForms isn't a major concern, but I do think that avoiding a problem 
for those that will be using various flavors of XHTML with  XForms is worth 
addressing now.  If XForms were to add an explicit dialog box element, what 
name other than  would be appropriate?

[1] http://www.w3.org/MarkUp/Forms/wiki/Dialogs

Re: [whatwg] Thoughts on HTML 5 - dialog

[Zachary Carter]

FWIW, in my first encounter with HTML5  I assumed it meant a
dialog box. This might be due to my experience with the 
element in XUL[1], which is used for that. Also, dialog boxes are
generally more common from my browsing experience, so I hadn't
considered the alternative usage at first.

[1]http://developer.mozilla.org/en/docs/XUL:dialog

On Tue, May 13, 2008 at 8:08 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Tue, 13 May 2008, Ernest Cline wrote:
>  >
>
> > I agree that the word "discourse" is more formal than "dialog", but it
>  > does cover both formal and informal speech unlike some other thesaurus
>  > inspired possibilities such as "colloquy" or "chat".
>
>  Sure, I'm just reluctanct to use an element name that is too formal, as
>  (for better or worse) that makes the language sound stilted.
>
>
>
>  > It does have the advantage over dialog of avoiding the spelling issue
>  > and the computer term issue.  If those issues end up being judged
>  > sufficient to make  undesirable, then  seems to me
>  > to be the best alternative available among English words.  Of course, if
>  > words were abandoned altogether  would also be a possibility.
>
>   is probably too short for an element that won't be used that much.
>
>  Unless we get more evidence that the confusion with dialog boxes is a real
>  blocker to adoption, I'm going to assume that  is our best option.
>
>
>
>  --
>  Ian Hickson   U+1047E)\._.,--,'``.fL
>  http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
>  Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Zach Carter

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ian Hickson]

On Tue, 13 May 2008, Ernest Cline wrote:
> >
> >Unless we get more evidence that the confusion with dialog boxes is a 
> >real blocker to adoption, I'm going to assume that  is our best 
> >option.
> 
> Is there any reasonable chance an element for a dialog box might end up 
> being added to XForms?  (There is a proposal mentioned on the XForms 
> wiki [1] for a possible dialog element for XForms 2.0, but I have no 
> idea how much of a chance that proposal has as opposed to extending the 
> message element.) I know that XHTML 5 + XForms isn't a major concern, 
> but I do think that avoiding a problem for those that will be using 
> various flavors of XHTML with XForms is worth addressing now.  If XForms 
> were to add an explicit dialog box element, what name other than 
>  would be appropriate?

There are a number of other much more important conflicts between XForms 
and HTML at this point, I don't think this is a particularly big concern.


On Wed, 14 May 2008, Karl Dubost wrote:
> 
> food for thoughts
> 
> *  (probably too long)
> *   (probably too IRC, messenger oriented, though here
>I suspect my own distortion field. People often says
>"let's have a chat".)
> *   (was wondering if it was less geeky than dialog, not sure)
> * 

These have been suggested in recent threads.


> * 

I would imagine this would confuse more people than .


> * 

This has the same problem as , which was also suggested recently.


> * 
> * 

These are not in the same style (nouns) as other tags, which would lead to 
a language consistency problem.


On Tue, 13 May 2008, Zachary Carter wrote:
>
> FWIW, in my first encounter with HTML5  I assumed it meant a 
> dialog box. This might be due to my experience with the  element 
> in XUL[1], which is used for that. Also, dialog boxes are generally more 
> common from my browsing experience, so I hadn't considered the 
> alternative usage at first.

I agree that the initial name, if that's all you see, has the opportunity 
to confuse, but once you read what the element was really for, did the 
confusion continue to be a problem?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Thoughts on HTML 5 - dialog

[Mike Wilson]

Zachary Carter wrote:
> FWIW, in my first encounter with HTML5  I assumed it meant a
> dialog box.

Yes, I assumed the same thing. I think it would be better to not use 
such an overloaded term for the stated purpose.

The spec itself uses "dialog" in both meanings:
  3.4.6 ... tabbed dialogs ... (= dialog box)
  3.9.5 dialog element (= conversations)
  4.2   ... showModalDialog (= dialog box)
  4.5.1 Simple dialogs (= dialog boxes)

I think it would be better to choose any other word from the
suggested ones, as I think most of them do not already have
another meaning within the HTML5 spec.
The first paragraph of 3.9.5 gives a hint:
  "The dialog element represents a conversation."
so my first recommendation would be to go for  and
live with its length.

Many other element names are abbreviated so could also opt for
that:
  
   ("spoken dialog")
etc etc.

Ian Hickson wrote:
> I agree that the initial name, if that's all you see, has the 
> opportunity 
> to confuse, but once you read what the element was really 
> for, did the 
> confusion continue to be a problem?

Personally, I guess I can learn the intended meaning of the 
element. But, each time I see the element there is a feeling that 
this is wrong and I have to focus to remember the element's real 
purpose.
I guess this is what more people are feeling and that this is
why you are getting so much feedback on this fairly simple issue.

Best regards
Mike Wilson

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ian Hickson]

On Wed, 14 May 2008, Mike Wilson wrote:
> 
> Yes, I assumed the same thing. I think it would be better to not use 
> such an overloaded term for the stated purpose.

I agree in principle, but the alternatives, e.g.:

> so my first recommendation would be to go for  and live 
> with its length.
> 
> Many other element names are abbreviated so could also opt for
> that:
>   
>("spoken dialog")

...are all worse (far too long in the case of the first suggestion above, 
and inconsistent with the style of the rest of the language for the other 
two). Some words have multiple meanings, and when we introduce elements 
that use those words it can initially be confusing, but I'm sure than ten 
years from now people will by and large not have a problem with it, just 
like by and large people don't have a problem with 

Re: [whatwg] Thoughts on HTML 5 - dialog

[Mikko Rantalainen]

Ian Hickson wrote:
> On Tue, 13 May 2008, Ernest Cline wrote:
> I agree that  isn't perfect and could be (and has been) confused 
> with dialog boxes, but I'm not convinced it's not the best name for the 
> job anyway.
> 
>> The other possibility is  since the computing uses that cause 
>> confusion seem to have standardized on the shorter spelling.
> 
> Experience with language="" on 

Re: [whatwg] Thoughts on HTML 5 - dialog

[Tab Atkins Jr.]

On Wed, May 14, 2008 at 3:36 AM, Mikko Rantalainen <
[EMAIL PROTECTED]> wrote:

> If  is used instead of  then it should be designed in
>> a such way that it can be used for dialog box in addition to dialogue
>> (e.g. chat) in the future.
>
>  I severely doubt this is possible or desirable.  It would make it *more*
confusing, I think, if  was meant for dialog boxes *and* marking up
conversations.

Just to throw out yet another possibility, how about ?  I don't like
it too much, but it at least avoids most of the issues that plagued the
other submissions.  I'm generally convinced that  is an okay choice
for this, but if we *were* to change, I at least want to make sure it's
something I can get behind.

My personal favorite alternate suggestion so far has been .  Short and a
little confusing?  Maybe.  But it has the benefit of being unambiguous and
parallels existing tags with similar syntax.  But meh, it's probably not
quite right, as  isn't meant to be illustrating a conversation list,
but rather is a list illustrating a conversation.

~TJ

>
>

Re: [whatwg] Thoughts on HTML 5 - dialog

[fantasai]

Ian Hickson wrote:


On Tue, 13 May 2008, Zachary Carter wrote:
FWIW, in my first encounter with HTML5  I assumed it meant a 
dialog box. This might be due to my experience with the  element 
in XUL[1], which is used for that. Also, dialog boxes are generally more 
common from my browsing experience, so I hadn't considered the 
alternative usage at first.


I agree that the initial name, if that's all you see, has the opportunity 
to confuse, but once you read what the element was really for, did the 
confusion continue to be a problem?


Of course most people using these elements won't be reading the spec.
It is quite likely that someone will assume  is the "correct"
tag to use for a CSS+JS dialog box.

~fantasai

Re: [whatwg] Thoughts on HTML 5 - dialog

[Scott Hess]

On Wed, May 14, 2008 at 11:37 AM, fantasai
<[EMAIL PROTECTED]> wrote:
> Ian Hickson wrote:
>> On Tue, 13 May 2008, Zachary Carter wrote:
>>> FWIW, in my first encounter with HTML5  I assumed it meant a
>>> dialog box. This might be due to my experience with the  element in
>>> XUL[1], which is used for that. Also, dialog boxes are generally more common
>>> from my browsing experience, so I hadn't considered the alternative usage at
>>> first.
>>
>> I agree that the initial name, if that's all you see, has the opportunity
>> to confuse, but once you read what the element was really for, did the
>> confusion continue to be a problem?
>
> Of course most people using these elements won't be reading the spec.
> It is quite likely that someone will assume  is the "correct"
> tag to use for a CSS+JS dialog box.

They are reasonably unlikely to ship a web page that assumes that, though.

People who don't read specs generally build web pages by copying and
pasting from other web pages.  They don't just think up random things
they'd like to see and try them out to see if they work.  So people
looking for a dialog box are going to be looking for an example with a
dialog box, which will _not_ reference the  element, so they
won't be particularly confused.  People looking for an example of how
to express back-and-forth dialogue will find a web page which does so,
which does use the  element, and they will also not be
confused.  Or at least they won't be materially more or less confused
than they would be if the tag was  or something (al for
"alternating list").

-scott

Re: [whatwg] Thoughts on HTML 5 - dialog

[Charles]

My personal favorite alternate suggestion so far has been .

 

, anyone? Of course it's not pronounced that way.

 

- Charles

 

Re: [whatwg] Thoughts on HTML 5 - dialog

[Keryx Web]

Ernest Cline wrote:

The only synonym of dialog that is anywhere near as general seems to be . 


And I accidentally replied off list:

Discourse is too general.

In philosophy and theology a discourse can mean "teaching", as in 
"Levinas' discourse about 'the other' has made alterity a recurring 
theme in all modern philosophy" or "pentecostal theology is defined by 
its discourse about the charims".


I would not associate  with a spoken list-like dialog. That 
would be way too narrow.



Lars Gunther

Re: [whatwg] Thoughts on HTML 5 - dialog

[Mike Wilson]

Tab Atkins Jr. wrote:
> My personal favorite alternate suggestion so far has 
> been . 

Yes, I also quite like the analogy with dl/ul/ol. But it may
be confusing when using dt and dd as child elements (as in
the current spec for dialog):
  


...
  

That could be resolved by introducing elements ct and cd:
  


...
  

and that I guess can be regarded as making things better OR
worse depending on your focus...

Best regards
Mike Wilson

Re: [whatwg] Thoughts on HTML 5 - dialog

[Ernest Cline]

-Original Message-
>From: Mike Wilson <[EMAIL PROTECTED]>
>Sent: May 15, 2008 8:02 AM
>To: 'WHATWG' <[EMAIL PROTECTED]>
>Subject: Re: [whatwg] Thoughts on HTML 5 - dialog
>
>Yes, I also quite like the analogy with dl/ul/ol. But it may
>be confusing when using dt and dd as child elements (as in
>the current spec for dialog):
>  
>
>
>...
>  
>
>That could be resolved by introducing elements ct and cd:
>  
>
>
>...
>  
>
>and that I guess can be regarded as making things better OR
>worse depending on your focus...
>
>Best regards
>Mike Wilson

Because of the backwards compatibility using  and  with a new dialog 
element would have with most existing UA's, I'd be leery of changing the names 
unless additional types of child elements for  (by whatever name it 
gets) were added, such as an element to markup stage directions, audience 
response, or the like.  Then, since we'd be introducing enough new stuff to 
break compatibility anyway:


  (what  currently is)
  (what  currently is)
  (a new element for stage effects, audience response etc.)

Re: [whatwg] Thoughts on HTML 5 - dialog

[Tab Atkins Jr.]

On Thu, May 15, 2008 at 6:20 PM, Ernest Cline <[EMAIL PROTECTED]>
wrote:

>
>
> -Original Message-
> >From: Mike Wilson <[EMAIL PROTECTED]>
> >Sent: May 15, 2008 8:02 AM
> >To: 'WHATWG' <[EMAIL PROTECTED]>
> >Subject: Re: [whatwg] Thoughts on HTML 5 - dialog
> >
> >Yes, I also quite like the analogy with dl/ul/ol. But it may
> >be confusing when using dt and dd as child elements (as in
> >the current spec for dialog):
> >  
> >
> >
> >...
> >  
> >
> >That could be resolved by introducing elements ct and cd:
> >  
> >
> >
> >...
> >  
> >
> >and that I guess can be regarded as making things better OR
> >worse depending on your focus...
> >
> >Best regards
> >Mike Wilson
>
> Because of the backwards compatibility using  and  with a new
> dialog element would have with most existing UA's, I'd be leery of changing
> the names unless additional types of child elements for  (by
> whatever name it gets) were added, such as an element to markup stage
> directions, audience response, or the like.  Then, since we'd be introducing
> enough new stuff to break compatibility anyway:
>
> 
>   (what  currently is)
>   (what  currently is)
>   (a new element for stage effects, audience response etc.)


Yeah, I'm backing off of that position...  I'm back to liking plain 
or .  Either sounds great to me.

~TJ