Re: [whatwg] several messages about HTML5

[Elliotte Harold]

Keryx Web wrote:

If I were to add one thing to that interview it would be what I call 
"educational entropy". The teaching of web design and technologies 
deteriorates over time, just because time passes.


Sometimes, but not always. For me it seems to be more of a curve. The 
course improves for the first few years, and then deteriorates because 
you get accustomed to the old notes and resist radical rethinks that may 
be necessary.


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

Re: [whatwg] several messages about HTML5

[Keryx Web]

Ian Hickson wrote:
Probably the best we can do is design the language to make "the right 
thing" easier, and invest more heavily in education. In this regard HTML 
is in the same boat as more important subjects; I imagine that as we 
improve the quality of education in general, understanding of the 
importance of accessibility and related topics will improve as well.




Improving education is easier said than done. My efforts so far has been 
not too successful: 
http://www.webstandards.org/action/edutf/interviews/gunther-en/


If I were to add one thing to that interview it would be what I call 
"educational entropy". The teaching of web design and technologies 
deteriorates over time, just because time passes. It is a tough job 
teaching these things, keeping up to date and imparting that knowledge 
in a pedagogical way. I can share more horror stories than I would like 
to believe existed.


If I as a teacher would want anything from a spec, it would be that it 
said "this is wrong" and "this is right" in such a way that it becomes 
an instrument in grading. Most teachers will *not* invest the effort of 
learning best practices or keeping themselves up to date. Most school 
leaders will not provide them with enough money to attend good 
conferences or seminars. The technology must enforce it upon them.


At least in Sweden front end web development is seen as an easy subject. 
There is not one single course that deals with that subject on an 
advanced educational level. Not one single university offers such a 
course, not even the ones that offer special programs for web developers!


A few years ago Sweden was a leading country in adopting the web. In a 
few years I suppose we will be seen as the retarded cousin from name of choice>.



Lars Gunther

Re: [whatwg] several messages about HTML5 -- authors' tools

[ddailey]

Interesting thread (including various sub-ravels thereof).

Suppose in a semantically charged, but markup-impoverished medium such as 
the textual narrative (constituting the majority of the content of the web 
as we know it), we seek to build the word processor that generates not only 
the surface structure (the sentences and paragraphs) but the semantic 
structure as well. How do we minimize the author's effort? Authors will not 
want to write both their utterances and the translation of those utterances 
into semantic tags -- it is simply too labor intensive (unless we care more 
about form than substance and chose to purge ill-formed ideas from the human 
corpus).


Rather we may seek a word-processor that deduces semantics from authors' 
expressions. Yeah, without the existence of full-blown AI (which has been a 
while in coming, now), 40% (or so) of such deductions will be incorrect. But 
suppose following the creation of a sentence, or a paragraph, or a larger 
chunk of text, semantically enabled software were to pose to the author a 
finite (and hopefully small) number of "deductive disambiguators"?


"Dear author, did you mean to imply that AI will indeed, be arriving soon?"

"Dear author, who exactly does 'we' refer to in the above paragraph -- I'm 
sorry, but I see no people mentioned before?"


Using a relatively simply inference engine (SFOL + set theory + predicate 
calculus + arithmetic + time + causality + modal logic) coupled with 
thesauri and parsers (all available client-side these days), and (most 
importantly) the author's expert intervention,  I rather suspect that the 
40% (incorrect deductions) could be brought down to 8% with an additional 
cost of 20% in authorial time investment. With current software that most 
folks use, and requiring authors to generate their own semantics, I think we 
might expect to achieve 5% spurious deduction with 400% additional 
investment of authors' time. The cost-benefit ratio is just too high with 
current desktop tools.


In semantically impoverished (not in the evocative space it engenders, but 
in the surface expression of its utterance) but markup-rich environments 
such as SVG, the generation of a parallel semantic substrate is going to be 
a lot more difficult, but maybe that's why we have things like sXBL: to 
allow semantics to be imported from other disciplines.


That's one approach. Another is to build a semantic expression system for 
which we abandon our native languages and agree to write in a semantic 
shorthand (with lots of parentheses, by the way). For even one language, the 
task of finding a minimal set of semantic primitives (from its monolingual 
dictionary) is NP-complete, but if we seek such a shorthand to span the 
space of human semantics, it may take longer to bring into existence than AI 
itself . The different language families I have looked at probably share a 
core semantics of only about 20% of the expressive space of any one language 
by itself. The nice thing about such languages is that people from different 
linguistic backgrounds can all read the same text; the hassle is that it's 
hard to translate ordinary expressions into such languages.


cheers,
David Dailey

- Original Message - 
From: "Elliotte Harold" <[EMAIL PROTECTED]>

To: "Ian Hickson" <[EMAIL PROTECTED]>
Cc: ; "Vlad Alexander (xhtml.com)" 
<[EMAIL PROTECTED]>

Sent: Wednesday, February 21, 2007 4:34 PM
Subject: Re: [whatwg] several messages about HTML5



Ian Hickson wrote:

The original reason I got involved in this work is that I realised that 
the human race has written literally billions of electronic documents, 
but without ever actually saying how they should be processed.


That's a feature, not a bug.

If, in a thousand years, someone found a trove of HTML documents and 
decided they
would right an HTML browser to view them, they couldn't do it! Even with 
the existing HTML specs -- HTML4, SGML, DOM2 HTML, etc -- a perfect 
implementation couldn't render the vast majority of documents as they 
were originally intended.




Authorial intent is a myth. Documents don't have to be rendered like the 
author intended, nor should we expect them to be.  We don't read Homer 
like Homer intended, but we still read him, well more than a thousand 
years later. (For one thing Homer actually intended that people listen to 
the poems, not read them.)


This is not to say that I don't think it's useful to define a standard 
tree structure for documents. It is useful. However the benefit of this 
exercise is not in maintaining authorial intent. That's tilting at 
windmills, and will never succeed no matter what we do.


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

Re: [whatwg] several messages about HTML5

[Charles McCathieNevile]

On Wed, 21 Feb 2007 22:38:48 +0100, Elliotte Harold <[EMAIL PROTECTED]> wrote:

> ... most of the tools that
> have been built have been built by programmers with more experience in
> WYSIWYG word processors than in semantic markup. The semanticists who
> have built GUI tools have not had the necessary user interface design
> skills to produce working programs. What is needed is some work by
> people who understand both domains.

Indeed. And to get users to use them, as has been noted. Actually there have 
been good semanticists working with Word and Dreamweaver. As someone (Sander?) 
noted, success might come faster from systems dedicated to doing a small task - 
CMS, blog systems, etc.

Then again...

As Adrian said, it is pretty difficult. I worked on it long enough to 
understand that, if not to come up with all the answers ;). But I am not 
convinced that it cannot be done, any more than I expect it to be an 
unquestioned success within my lifetime. Like peace in the Middle East, it's 
still a worthwhile goal we should actively strive for, IMHO.

cheers

Chaals

-- 
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
[EMAIL PROTECTED]  Try Opera 9.1 http://opera.com

Re: [whatwg] several messages about HTML5

[Michel Fortin]

Le 2007-02-21 à 11:34, David Latapie a écrit :

I think it'd be useful to have that on rel values (link types) as  
well.


rel="microformat"?


The rel attribute is about links. What I meant by that is that I  
think it would be useful to have a private domain for link types too.  
It would work a little differently than on class though, because the  
current spec disallows unregistered link types while it allows  
unregistered class names. My proposal would be to allow unregistered  
link types if they start with a dash "-".




 - - -

By the way, it would certainly be more coherent if unregistered class  
names were disallowed too (unless they start with a dash), but that  
would also make countless documents non-conformant with HTML5 so I'm  
not sure it's a so good idea. I can't say I dislike the idea though.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] several messages about HTML5

[Elliotte Harold]

Michel Fortin wrote:

t that, I would like to suggest that the current text be changed to 
reserve class names starting with a dash "-" for private use. That way 
that we would have a pool of class names which are guarantied to not be 
taken over later when new predefined class names are added.


Good idea. Should we follow MIME types, and maybe make these x- instead 
of simply -?


Also, should we reserve one spac eof names for the spec? e.g. html-?


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

Re: [whatwg] several messages about HTML5

[Benjamin Hawkes-Lewis]

Elliotte Harold wrote:

> Authorial intent is a myth. 

Presumably you don't mean that authors don't have intents, but rather
than authorial intent is ultimately irrecoverable. That's true, but it's
not necessarily an especially useful truth (in this context). All
communication involves translation, and something invariably gets "lost"
in translation. But if you want to arrive at an approximation of what an
original interlocutor meant (which is what we usually want to do), you
want an interpreter who attempts to capture, however remotely, the
original meaning, not somebody who just makes stuff up. Partial
knowledge is better than no knowledge.

--
Benjamin Hawkes-Lewis

Re: [whatwg] several messages about HTML5

[Elliotte Harold]

Vlad Alexander (xhtml.com) wrote:


Is it due to a flaw in HTML that it is difficult to build authoring tools, such 
as WYSIWYG editors, that generate markup rich in semantics, embody 
best-practices and can be easily used by non-technical people? Since much of 
the content on the Web is created using such authoring tools, can we ever 
achieve a semantically rich and accessible Web?



It is not difficult to build such tools, or at least not more difficult 
than building tools that do not maintain well-formedness. (assuming you 
really mean GUI rather than WYSIWYG.) However most of the tools that 
have been built have been built by programmers with more experience in 
WYSIWYG word processors than in semantic markup. The semanticists who 
have built GUI tools have not had the necessary user interface design 
skills to produce working programs. What is needed is some work by 
people who understand both domains.


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

Re: [whatwg] several messages about HTML5

[Elliotte Harold]

Ian Hickson wrote:

The original reason I got involved in this work is that I realised that 
the human race has written literally billions of electronic documents, but 
without ever actually saying how they should be processed. 


That's a feature, not a bug.

If, in a 
thousand years, someone found a trove of HTML documents and decided they
would right an HTML browser to view them, they couldn't do it! Even with 
the existing HTML specs -- HTML4, SGML, DOM2 HTML, etc -- a perfect 
implementation couldn't render the vast majority of documents as they were 
originally intended.




Authorial intent is a myth. Documents don't have to be rendered like the 
author intended, nor should we expect them to be.  We don't read Homer 
like Homer intended, but we still read him, well more than a thousand 
years later. (For one thing Homer actually intended that people listen 
to the poems, not read them.)


This is not to say that I don't think it's useful to define a standard 
tree structure for documents. It is useful. However the benefit of this 
exercise is not in maintaining authorial intent. That's tilting at 
windmills, and will never succeed no matter what we do.


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

Re: [whatwg] several messages about HTML5

[Elliotte Harold]

James Graham wrote:

Even in cases where the content really is well formed XML the client is 
entirely the wrong place to enforce validity -- it means that a tiny 
mistake causes suffering for the person least able to deal with the 
problem -- the end user. Needless to say this is terrible UI and thus 
widespread implementation of fatal error handling is, at best, a 
metastable situation -- as soon as one UA decides they can gain some 
advantage by including error handling, everyone else has to follow suit. 
This has happened with many "XML" based feed formats, for example.




That's an interesting argument, and it seems logically sound. However, 
something's wrong with it, though I can't quite place my finger on where 
exactly the mistake lies.


The reason I know that something's wrong with it is that the conclusion 
is not seen in the wild today. Feed readers are in fact swinging away 
from permissive error handling, and are increasingly choosing to simply 
reject malformed feeds, and not bother trying to handle it. Consequently 
far more feeds today are well-formed than was the case a few years ago.


This may be the result of increasing use of better software to generate 
feeds than the homegrown hacks we used a few years ago. WordPress, 
Blogger, and such account for a much larger percentage of the installed 
base than they used to.


There is of course a snowball effect. As more feed readers reject 
ill-formed feeds, blogs have greater incentives to produce well-formed 
feeds.


The same effect may be possible in the web browser space as well. 
However I think it would have to start with better authoring tools and 
template systems.


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

Re: [whatwg] several messages about HTML5

[Martin Atkins]

Benjamin Hawkes-Lewis wrote:

James Graham wrote:
Obviously I would love to be proven wrong but given the 
limited success in this field in the last decade, I'm not holding my breath.


What actual attempts have been made in this field, that could be judged
relative successes or failures?



The best category of software to use for examples is that of "WYSIWYG" 
XML editors. These generally try to get users to specify semantics while 
simultaneously showing them the presentational result of those semantics 
 and constraining them to some kind of schema.


For example:
http://xopus.com/
http://www.syntext.com/products/serna/
http://bitfluxeditor.org/

Whether they have been a successes or failures I'll leave for others to 
decide.

Re: [whatwg] several messages about HTML5

[Ian Hickson]

On Wed, 21 Feb 2007, David Latapie wrote:
> > 
> > It's the first really open, collaborative community that has taken on 
> > a task of this magnitude
> 
> AFAICR from Daniel Glazman’s ParisWeb 2006 conference, before W3C, 
> IETF [HTML WG] was really open too -- problem seemed to be it was too 
> much open, but I don't know enough of Web history. So WHATWG may be 
> called the “*second* really open, collaborative community”. Or, to 
> put it in a more optimistic light, a “‘back to the origins’ 
> movement.”

That's a fair point, actually. The IETF has done a good job of being open. 

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

Re: [whatwg] several messages about HTML5

[David Latapie]

On Wed, 21 Feb 2007 17:28:16 +0200, Henri Sivonen wrote:
> Actually, the fact that many native English speakers cannot write 
> "it's" vs. "its" or "they're" vs. "their" vs. "there" correctly 
> suggests that people have a tendency to think in terms of aural 
> *presentation* of the language instead of the *semantics* of the 
> language.

I can say the same for the French language: common written mistake are 
the ones for wich there is no aural difference.

When I have to decide for either  or , I just say my 
sentence out loud; if I tend to mark a small pause after the emphasized 
element, I use , if not I use .

These are two arguments for the aural, but YMMV.
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] several messages about HTML5

[David Latapie]

On Wed, 21 Feb 2007 17:10:42 +0100, Anne van Kesteren wrote:
> On Wed, 21 Feb 2007 16:56:56 +0100, David Latapie <[EMAIL PROTECTED]> wrote:
>> I don't say so just for nitpicking, but would also appreciate feedbacks
>> from people who were already there by IETF times; what are the
>> difference between “IETF time” and “WHATWG time” in the way of working?
> 
> Newsflash: IETF is still around.

I meant “the IETF HTML WG”
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] several messages about HTML5

[David Latapie]

On Tue, 20 Feb 2007 21:56:30 -0500, Michel Fortin wrote:
> Le 2007-02-20 à 19:05, Ian Hickson a écrit :
> 
>> The proposal to have predefined class names is still very much in the air,
>> we're mostly waiting for author and implementation feedback to see if it
>> is workable. Currently the HTML5 spec leaves a number of things unanswered
>> (like what happens if two classes on an element are contradictory), so
>> it's definitely not finished.
> 
> About that, I would like to suggest that the current text be changed 
> to reserve class names starting with a dash "-" for private use. That 
> way that we would have a pool of class names which are guarantied to 
> not be taken over later when new predefined class names are added. It 
> could even encourage some kind of namespacing for class names, in a 
> similar way that CSS extensions -- or not yet standardised features 
> -- are prefixed by the engine name like in -moz-border-radius or 
> -webkit-column-count.

This seems an interesting feature to consider. Maybe we shall reserve 
*two* class names=

• "-*" for experimental, as for CSS vendor profiles. Same prefix, same 
meaning and consequently easier to understand/adopt.

• "micro-*" for what Michel suggested (that is, class names that have a 
definitive meaning). I decided on micro, like microformat, but this is 
really just a suggestion and maybe a bad one (refer to the  element 
naming debate), so please investigate any other possibility.

> I think it'd be useful to have that on rel values (link types) as well.

rel="microformat"?

class="-footer" rel="microformat" and class="micro-footer" 
rel="microformat"?
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] several messages about HTML5

[Anne van Kesteren]

On Wed, 21 Feb 2007 16:56:56 +0100, David Latapie <[EMAIL PROTECTED]>  
wrote:

I don't say so just for nitpicking, but would also appreciate feedbacks
from people who were already there by IETF times; what are the
difference between “IETF time” and “WHATWG time” in the way of working?


Newsflash: IETF is still around.


--
Anne van Kesteren

Re: [whatwg] several messages about HTML5

[David Latapie]

On Wed, 21 Feb 2007 00:05:47 + (UTC), Ian Hickson wrote:
>  * Radical new benefits to offset the pain of change
>  * Backwards-compatibility with the old technology

I agree.

> It's the first really open, 
> collaborative community that has taken on a task of this magnitude

AFAICR from Daniel Glazman’s ParisWeb 2006 conference, before W3C, IETF 
was really open too -- problem seemed to be it was too much open, but I 
don't know enough of Web history. So WHATWG may be called the “*second* 
really open, collaborative community”. Or, to put it in a more 
optimistic light, a “‘back to the origins’ movement.”

I don't say so just for nitpicking, but would also appreciate feedbacks 
from people who were already there by IETF times; what are the 
difference between “IETF time” and “WHATWG time” in the way of working?
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] several messages about HTML5

[Henri Sivonen]

On Feb 21, 2007, at 16:39, Benjamin Hawkes-Lewis wrote:


Henri Sivonen wrote:


I think device independence and accessibility are worthwhile goals.
Semantic markup and separation of content and style are not essential
in themselves but just a means of pursuing the other goals.


Those aren't the /only/ goals of semantic markup and separation of
content and style. They also make sites easier to redesign.


Sure, but that's an authoring-side benefit involving the author and  
his/her future self or successor. It isn't an issue for arbitrary  
parties exchanging data over a world-wide network without prior  
bilateral agreement. That is, site maintenance as such is not an  
interchange issue.


Specs for the Web and related education campaigns should, in my  
opinion, first and foremost facilitate the communication of arbitrary  
parties without bilateral prior agreements. Making things easier in  
the private space of the author is good for the author but doesn't  
require others to work in the same ways (except to the extent working  
in the same ways creates demand for authoring tools which leads to  
tool availability).


Basically, if someone is being inefficient privately, it is his  
problem (less reason to demand him to change his ways). But if he is  
serving bad stuff to you, it is your problem, too (more reason to  
demand him to change his ways). The two can be related, though.


Of course, if communicating between arbitrary parties can be improved  
by acting on private selfish incentives, all the better. In fact, on  
the Web, the best way to get authors to act in common benefit is to  
make sure that acting to their own benefit has the side effect of  
being beneficial to the Web as a whole.



Well, to the extent most people keep semantics implicit and only
think about presentation explicitly, reconciling "natural" with
asking them to think differently is a problem.


In so far as this is true, it is true only when particular conventions
become exceptionally familiar. In unfamiliar cases (academic citation
formatting) or confusing cases ("it's" vs. "its"), people typically  
have
to resolve the semantics of what they are trying to format before  
trying

to apply a format to it.


Actually, the fact that many native English speakers cannot write  
"it's" vs. "its" or "they're" vs. "their" vs. "there" correctly  
suggests that people have a tendency to think in terms of aural  
*presentation* of the language instead of the *semantics* of the  
language.


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

Re: [whatwg] several messages about HTML5

[Benjamin Hawkes-Lewis]

Henri Sivonen wrote:

> I think device independence and accessibility are worthwhile goals.  
> Semantic markup and separation of content and style are not essential  
> in themselves but just a means of pursuing the other goals.

Those aren't the /only/ goals of semantic markup and separation of
content and style. They also make sites easier to redesign.

> Well, to the extent most people keep semantics implicit and only  
> think about presentation explicitly, reconciling "natural" with  
> asking them to think differently is a problem.

In so far as this is true, it is true only when particular conventions
become exceptionally familiar. In unfamiliar cases (academic citation
formatting) or confusing cases ("it's" vs. "its"), people typically have
to resolve the semantics of what they are trying to format before trying
to apply a format to it. However, the familiarity of conventions is
partly a function of the tools themselves, i.e. typewriter users were
used to different conventions. Given the wide variety of commenting
systems used on blogs and forums today on the one hand, and the enormous
variety in presentation on the web more generally on the other, I
wouldn't underestimate people's capacity to absorb new conventions.

--
Benjamin Hawkes-Lewis

Re: [whatwg] several messages about HTML5

[Henri Sivonen]

On Feb 21, 2007, at 07:14, Sander Tekelenburg wrote:

That's not a flaw in HTML, because it is essential to HTML that it  
separates content from presentation.


I think device independence and accessibility are worthwhile goals.  
Semantic markup and separation of content and style are not essential  
in themselves but just a means of pursuing the other goals.


My feeling is that many people can understand and work with that  
slightly abstract concept, but they need tools that make it easy.


People also need to believe that they benefit from thinking on a more  
abstract level.


If we can offer people 'semantic editors' that work in a 'natural'  
way, they won't have to fight.


Well, to the extent most people keep semantics implicit and only  
think about presentation explicitly, reconciling "natural" with  
asking them to think differently is a problem.


But I think before that education stands a chance of making a dent,  
there'll need to be good non-WYSIWYG authoring tools.


I agree. Do you have a plan on how you are going to convince  
developers to take the risk of incurring the cost of developing a new  
kind of tool which may not succeed with users?


Anyway, HTML5 needs to be realistic considering the immediate  
evolvability of existing tools.


P.S. This should not be considered a pro- message. I think the  
 element should be dropped and the style='' attribute should be  
allowed on all elements.


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

Re: [whatwg] several messages about HTML5

[Gervase Markham]

Anne van Kesteren wrote:
The analogy I tried to make (apparently it failed) is that design 
decisions for C/C++ are not necessarily good for HTML.


Right. But they aren't necessarily bad either. What is wrong with 
picking a clean rather than a dirty namespace for predefined class 
names? Or does "-footer" rather than "footer" offend your sense of 
aesthetics? :-)


Gerv

Re: [whatwg] several messages about HTML5

[James Graham]

Gervase Markham wrote:
(I guess I'm making an underlying assumption here that there aren't 
loads of existing pages on the web using HTML 5 predefined class names 
while expecting HTML 5 rendering and semantics for them. But, unless I'm 
missing something, that seems like a reasonable assumption.)


I think the class names in the spec have been chosen specifically because there 
are lots of pages serendipitously using those class names for content with the 
specified semantics. This will no longer be the case if the "-" prefix is added. 
Clearly there is soom room for debate on whether the advantages of adding 
accurate semantic information to many pages is outweight by the disadvantage of 
adding inaccurate information to a few pages.


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

Re: [whatwg] several messages about HTML5

[Anne van Kesteren]

On Wed, 21 Feb 2007 11:33:36 +0100, Gervase Markham <[EMAIL PROTECTED]>  
wrote:
I don't see how the analogy holds. Why is using a fairly clean namespace  
for predefined class names instead of a well-used one the same sort of  
thing as having HTML parsers stop at the first error?


The analogy I tried to make (apparently it failed) is that design  
decisions for C/C++ are not necessarily good for HTML.



--
Anne van Kesteren

Re: [whatwg] several messages about HTML5

[Gervase Markham]

Anne van Kesteren wrote:
On Wed, 21 Feb 2007 10:41:12 +0100, Gervase Markham <[EMAIL PROTECTED]> 
wrote:
Surely it would make much more sense to have all the predefined class 
names start with a dash? After all, XHTML5 is not yet standardised, 
whereas people have been using all sorts of random class names for 
years - but, I suspect, mostly without a leading dash.


This is similar to the C/C++ thing of having reserved symbols like 
__LINE__ start with an underscore.


Surely it would make much more sense to have HTML parsers should stop at 
the first error too. This is similar to C/C++ compilers throwing an 
error at you.


I don't see how the analogy holds. Why is using a fairly clean namespace 
for predefined class names instead of a well-used one the same sort of 
thing as having HTML parsers stop at the first error?


(I guess I'm making an underlying assumption here that there aren't 
loads of existing pages on the web using HTML 5 predefined class names 
while expecting HTML 5 rendering and semantics for them. But, unless I'm 
missing something, that seems like a reasonable assumption.)


Gerv

Re: [whatwg] several messages about HTML5

[Benjamin Hawkes-Lewis]

James Graham wrote:
> Obviously I would love to be proven wrong but given the 
> limited success in this field in the last decade, I'm not holding my breath.

What actual attempts have been made in this field, that could be judged
relative successes or failures?

--
Benjamin Hawkes-Lewis

Re: [whatwg] several messages about HTML5

[Anne van Kesteren]

On Wed, 21 Feb 2007 10:41:12 +0100, Gervase Markham <[EMAIL PROTECTED]>  
wrote:
About that, I would like to suggest that the current text be changed to  
reserve class names starting with a dash "-" for private use. That way  
that we would have a pool of class names which are guarantied to not be  
taken over later when new predefined class names are added.


Surely it would make much more sense to have all the predefined class  
names start with a dash? After all, XHTML5 is not yet standardised,  
whereas people have been using all sorts of random class names for years  
- but, I suspect, mostly without a leading dash.


This is similar to the C/C++ thing of having reserved symbols like  
__LINE__ start with an underscore.


Surely it would make much more sense to have HTML parsers should stop at  
the first error too. This is similar to C/C++ compilers throwing an error  
at you.



--
Anne van Kesteren

Re: [whatwg] several messages about HTML5

[Gervase Markham]

Michel Fortin wrote:
About that, I would like to suggest that the current text be changed to 
reserve class names starting with a dash "-" for private use. That way 
that we would have a pool of class names which are guarantied to not be 
taken over later when new predefined class names are added. 


Surely it would make much more sense to have all the predefined class 
names start with a dash? After all, XHTML5 is not yet standardised, 
whereas people have been using all sorts of random class names for years 
- but, I suspect, mostly without a leading dash.


This is similar to the C/C++ thing of having reserved symbols like 
__LINE__ start with an underscore.


Gerv

Re: [whatwg] several messages about HTML5

[James Graham]

Lachlan Hunt wrote:
It's not so much a flaw in HTML's design, as it is the refusal of 
popular WYSIWYG editor vendors to replace common presentational UIs, 
such as font styles and colours, with much more useful semantic UIs.  I 
don't believe it's particularly difficult to achieve.


The difficult problem is not to produce an editor that encourages the 
use of semantic markup, it is to produce an editor that encourages the 
use of semantic markup and would be chosen in preference to e.g. MS 
Frontpage or Dreamweaver by the typical WYSIWYG user. To me it seems 
likely that this problem is intrinsically hard as you must squeeze the 
/more/ information out of the /same/ amount of mental effort on the part 
of the user. Obviously I would love to be proven wrong but given the 
limited success in this field in the last decade, I'm not holding my breath.


--
"The universe doesn't care what you believe. The wonderful thing about 
science is that it doesn't ask for your faith, it just asks for your 
eyes" --- http://xkcd.com/c154.html

Re: [whatwg] several messages about HTML5

[Sander Tekelenburg]

At 21:21 -0500 UTC, on 2007-02-20, Vlad Alexander (xhtml.com) wrote:

[...]

> Is it due to a flaw in HTML that it is difficult to build authoring tools,
> such as WYSIWYG editors, that generate markup rich in semantics, embody
> best-practices and can be easily used by non-technical people?

I think a big part of this problem is that WYSIWYG does not and never will
apply to the Web. Period. As long as you think in those terms, this problem
cannot be solved. And as someone else said, most authoring tools still try to
be WYSIWYG, and thus fail.

That's not a flaw in HTML, because it is essential to HTML that it separates
content from presentation. My feeling is that many people can understand and
work with that slightly abstract concept, but they need tools that make it
easy. Trying to achieve this with a wannabe-WYSIWYG editor is going to be a
fight. If we can offer people 'semantic editors' that work in a 'natural'
way, they won't have to fight.

People will still have to get used to the idea of course. Ian's mention of
education applies. But I think before that education stands a chance of
making a dent, there'll need to be good non-WYSIWYG authoring tools.

Figuring out the right interface for such a semantic editor will be one of
the biggest challenges. It'll require teaming up with people in other fields,
who have studied how people learn; how minds work. (Sort of like what Apple
did when they first designed their GUI.)

The Web Repair Initiative aims to take on this challenge:
.

> Since much of the content on the Web is created using such authoring tools,
>can we ever achieve a semantically rich and accessible Web?

IMO it makes it in fact more achievable. Although it will be a quite an
undertaking to improve authoring tools, it is still much easier than to
succesfully preach to each and every webdesigner out there... I consider this
shift towards using HTML generators an opportunity to get closer to a
semantically rich and accessible Web.


-- 
Sander Tekelenburg
The Web Repair Initiative: 

Re: [whatwg] several messages about HTML5

[Karl Dubost]

Le 21 févr. 2007 à 11:40, Lachlan Hunt a écrit :
It's not so much a flaw in HTML's design, as it is the refusal of  
popular WYSIWYG editor vendors to replace common presentational  
UIs, such as font styles and colours, with much more useful  
semantic UIs.  I don't believe it's particularly difficult to  
achieve.  It just requires thinking outside the box a little and  
not simply copying what typical word processing software has done  
in the past.


We are touching one of the mistakes here I think. Having the  
authoring tools developers involved in the development of HTML. In  
HTML world, browsers are often considered as first class citizens,  
and authoring tools as secondary. I would expect them to be on the  
same level, but for this we have to make an extra effort to convince  
them to join the table not only implementing but discussing the  
technology.




--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] several messages about HTML5

[Karl Dubost]

Le 21 févr. 2007 à 11:39, Ian Hickson a écrit :

On Tue, 20 Feb 2007, Vlad Alexander (xhtml.com) wrote:


...We could require editors to do this, but since nobody knows  
how to

do it, it would be a stupid requirement. ...


Is it due to a flaw in HTML that it is difficult to build authoring
tools, such as WYSIWYG editors, that generate markup rich in  
semantics,

embody best-practices and can be easily used by non-technical people?


No, I think it's just something that is fundamentally hard. People  
think
visually, trying to ask a Web designer to think in terms of (e.g.)  
headers
instead of font sizes is just something that WYSIWYG implementors  
and UI

researchers simply haven't solved yet. Personally I don't think it's a
lost cause, but we're just not there yet.


"Web designer" the term is too broad.
There will be people concerned by markup structures, some not.  
Exactly the same way when people are using MS Office Word, which has  
two main modes: visual and structural. Structural mode in word helps  
to achieve indexes of figures, table of contents, automatic styling.


I do not think it relies on categories of people but more on ROI  
(Return On Investment), if someone has benefits structuring  
information, they will do it. If there are no *direct and personal*  
benefits, they will not do it, except if constrained.


Constrains can be "controlled editing" for example. What I mean is  
the type of editing, there is in an Addressbook, in a library  
software, in Web services with UIs driven by AJAX (photo services,  
messaging, calendaring, etc.)


Constraining someone to make structural editing if he/she doesn't  
need it would be like constraining someone to structure the free note  
taking on the back of a paper envelop or how to organize a collage  
and text diary. It is likely to fail on massive scale. The question  
in this case is HTML the best technology to address sites like  
MySpace (scrapbook diary).




Since much of the content on the Web is created using such authoring
tools, can we ever achieve a semantically rich and accessible Web?


There will always be a continuum of sites from the unusable to the  
very
accessible. As with all fields of human endeavour, there will  
always be

the highly competent Web designers who understand fundamentally how to
build device-independent sites that cater to all kinds of users,  
and there
will always be the inexperienced and ignorant Web designers who  
think only
in terms of their own personal experience, targetting a specific  
browser

on a specific computer without taking into account any other potential
user experience.





Probably the best we can do is design the language to make "the right
thing" easier, and invest more heavily in education. In this regard  
HTML

is in the same boat as more important subjects; I imagine that as we
improve the quality of education in general, understanding of the
importance of accessibility and related topics will improve as well.


+1

--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] several messages about HTML5

[Karl Dubost]

Le 21 févr. 2007 à 09:05, Ian Hickson a écrit :

If we want to make HTML5 successful, we have to make sure the browser
vendors pay attention to it. Any requirements that make their  
market share

go down relative to browsers who aren't following the spec will
immediately be ignored.


it seems a reasonable thought, but there are at least two cases,  
where it has not been the case.


* CSS: text/plain versus text/css
* HTML: closing the TABLE element

We have to be careful on what we think will happen as much as we have  
to be careful on the reason of success of this and that. History is  
not an experiment and can't be tested and proved.


--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***

Re: [whatwg] several messages about HTML5

[Michel Fortin]

Le 2007-02-20 à 19:05, Ian Hickson a écrit :

The proposal to have predefined class names is still very much in  
the air,
we're mostly waiting for author and implementation feedback to see  
if it
is workable. Currently the HTML5 spec leaves a number of things  
unanswered

(like what happens if two classes on an element are contradictory), so
it's definitely not finished.


About that, I would like to suggest that the current text be changed  
to reserve class names starting with a dash "-" for private use. That  
way that we would have a pool of class names which are guarantied to  
not be taken over later when new predefined class names are added. It  
could even encourage some kind of namespacing for class names, in a  
similar way that CSS extensions -- or not yet standardised features  
-- are prefixed by the engine name like in -moz-border-radius or - 
webkit-column-count.


I think it'd be useful to have that on rel values (link types) as well.


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] several messages about HTML5

[Lachlan Hunt]

Vlad Alexander (xhtml.com) wrote:

Thank you Ian. Just one follow-up question. You wrote:

...We could require editors to do this, but since nobody knows how 
to do it, it would be a stupid requirement. ...


Is it due to a flaw in HTML that it is difficult to build authoring 
tools, such as WYSIWYG editors, that generate markup rich in 
semantics, embody best-practices and can be easily used by 
non-technical people? Since much of the content on the Web is created 
using such authoring tools, can we ever achieve a semantically rich 
and accessible Web?


It's not so much a flaw in HTML's design, as it is the refusal of 
popular WYSIWYG editor vendors to replace common presentational UIs, 
such as font styles and colours, with much more useful semantic UIs.  I 
don't believe it's particularly difficult to achieve.  It just requires 
thinking outside the box a little and not simply copying what typical 
word processing software has done in the past.


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

Re: [whatwg] several messages about HTML5

[Ian Hickson]

On Tue, 20 Feb 2007, Vlad Alexander (xhtml.com) wrote:
> > 
> > ...We could require editors to do this, but since nobody knows how to 
> > do it, it would be a stupid requirement. ...
> 
> Is it due to a flaw in HTML that it is difficult to build authoring 
> tools, such as WYSIWYG editors, that generate markup rich in semantics, 
> embody best-practices and can be easily used by non-technical people? 

No, I think it's just something that is fundamentally hard. People think 
visually, trying to ask a Web designer to think in terms of (e.g.) headers 
instead of font sizes is just something that WYSIWYG implementors and UI 
researchers simply haven't solved yet. Personally I don't think it's a 
lost cause, but we're just not there yet.


> Since much of the content on the Web is created using such authoring 
> tools, can we ever achieve a semantically rich and accessible Web?

There will always be a continuum of sites from the unusable to the very 
accessible. As with all fields of human endeavour, there will always be 
the highly competent Web designers who understand fundamentally how to 
build device-independent sites that cater to all kinds of users, and there 
will always be the inexperienced and ignorant Web designers who think only 
in terms of their own personal experience, targetting a specific browser 
on a specific computer without taking into account any other potential 
user experience.

Probably the best we can do is design the language to make "the right 
thing" easier, and invest more heavily in education. In this regard HTML 
is in the same boat as more important subjects; I imagine that as we 
improve the quality of education in general, understanding of the 
importance of accessibility and related topics will improve as well.

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

Re: [whatwg] several messages about HTML5

[Vlad Alexander (xhtml.com)]

Thank you Ian. Just one follow-up question. You wrote:

>...We could require editors to do this, but since nobody knows
> how to do it, it would be a stupid requirement. ...

Is it due to a flaw in HTML that it is difficult to build authoring tools, such 
as WYSIWYG editors, that generate markup rich in semantics, embody 
best-practices and can be easily used by non-technical people? Since much of 
the content on the Web is created using such authoring tools, can we ever 
achieve a semantically rich and accessible Web?

Re: [whatwg] several messages about HTML5

[Ian Hickson]

On Tue, 20 Feb 2007, Vlad Alexander (xhtml.com) wrote:
>
> 4. One of the biggest problems with HTML is that content authors can get 
> away with writing "tag soup".

Is it really a problem? Or is it the reason the Web is so wildly 
successful? Would the Web have taken off in the same way if it worked like 
most other systems, showing error messages whenever something was the 
least bit wrong?


> As a result, most content authors don't feel the need to write markup to 
> specification. When markup is not written to specification, CSS may not 
> get applied correctly, JavaScript may not execute and some user-agents 
> may not be able to process content as the author intended.

Having draconian error handling -- the term we use for just not allowing 
errors instead of having silent error recovery like HTML does -- is not 
the only solution for getting consistent behaviour between browsers. The 
approach that we have taken with HTML5 is to define what _any_ document 
means, even if it is invalid -- down to the last detail, so that every 
browser will handle every document in an equivalent way, whether the 
document is conformant or not. (It's the same technique CSS uses.)


> Why not put an end to "tag soup" by requiring user-agents to only accept 
> markup written to specification?

There are literally dozens if not hundreds of billions of documents 
already on the Web. A study of a sample of several billion of those 
documents with a test implementation of the HTML5 Parser specification 
that I did at Google put a very conservative estimate of the fraction of 
those pages with markup errors at more than 78%. When I tweaked it a bit 
to look at a few more errors, the number was 93%. And those are only core 
syntax errors -- it didn't count misuse of HTML, like putting a  
element inside an  element.

If we required browsers to refuse those documents, then you couldn't 
browse over 90% of the Web.

But consider -- if one browser showed error messages on half the Web, and 
another browser showed no errors and instead showed the Web roughly as the 
author intended. Which browser would the average person use?

If we want to make HTML5 successful, we have to make sure the browser 
vendors pay attention to it. Any requirements that make their market share 
go down relative to browsers who aren't following the spec will 
immediately be ignored.


> 5. X/HTML 5 has a construct for adding additional semantics to existing 
> elements using predefined class names. Predefined class names could be 
> the most controversial part of X/HTML 5, because the implementation 
> overloads the class attribute. XHTML 2 provides similar functionality 
> using the role attribute. Which approach is better and why?

The proposal to have predefined class names is still very much in the air, 
we're mostly waiting for author and implementation feedback to see if it 
is workable. Currently the HTML5 spec leaves a number of things unanswered 
(like what happens if two classes on an element are contradictory), so 
it's definitely not finished.

I haven't been able to work out what the role="" attribute does or how it 
is supposed to be implemented. It has a spec, but that spec is really 
unclear. So I can't really comment on it.


> 6. The font element is a terrible construct, primarily because content 
> creators using authoring tools use the font element instead of semantic 
> markup. The X/HTML 5 spec supports the font element when content is 
> authored using WYSIWYG editors. What is the rationale for this? Why 
> would WYSIWYG editors get an exemption? And is this exemption going to 
> make the Web less accessible?

Again, the whole  element and WYSIWYG section is up in the air, the 
current text is just a strawman and we've received lots of good feedback 
on it which will need to be taken into consideration.

The main reason that WYSIWYG editors would be given an exception is that 
the state of the art in user interface today doesn't have a good solution 
for making a semantic editor usable by the average person. We could 
require editors to do this, but since nobody knows how to do it, it would 
be a stupid requirement. Again, we have to compromise on perfection to 
actually address real-world needs and constraints.


> 7. The XHTML 5 spec says that "generally speaking, authors are 
> discouraged from trying to use XML on the Web". Why write an XML spec 
> like XHTML 5 and then discourage authors from using it? Why not just 
> drop support for XML (XHTML 5)?

Some people are going to use XML with HTML5 whatever we do. It's a simple 
thing to do -- XML is a metalanguage for describing tree structures, HTML5 
is a tree structure, it's obvious that XML can be used to describe HTML5. 
The problem is that if we don't specify it, then everyone who thinks it is 
obvious and goes ahead and does it will do it in a slightly different way, 
and we'll have an interoperability nightmare. So instead we bite the 
bullet and define how it must work i

Re: [whatwg] several messages about HTML5

[Matthew Paul Thomas]

On Feb 21, 2007, at 10:00 AM, Vlad Alexander (xhtml.com) wrote:


4. One of the biggest problems with HTML is that content authors can 
get away with writing "tag soup". As a result, most content authors 
don't feel the need to write markup to specification. When markup is 
not written to specification, CSS may not get applied correctly, 
JavaScript may not execute and some user-agents may not be able to 
process content as the author intended. Why not put an end to "tag 
soup" by requiring user-agents to only accept markup written to 
specification?

...


Because UA vendors compete, in part, on what proportion of Web pages 
work in their UA. Therefore, in the absence of greater opposing forces, 
competition will force them to ignore any requirement that they refuse 
to render a particular page.



...
6. The font element is a terrible construct, primarily because content 
creators using authoring tools use the font element instead of 
semantic markup. The X/HTML 5 spec supports the font element when 
content is authored using WYSIWYG editors. What is the rationale for 
this? Why would WYSIWYG editors get an exemption?


Because most people, including the vast majority of those using Wysiwyg 
editors, will never bother producing accurate semantic markup, and 
trying to force them to do so will cause them to misuse it.



And is this exemption going to make the Web less accessible?


Hopefully more accessible, because in those cases where semantic markup 
is used, UAs will be able to start relying on it being accurate.



...
8. The chair of the HTML Working Group at W3C, Steven Pemberton, said 
"HTML is a mess!" and "rather than being designed, HTML just grew, by 
different people just adding stuff to it". Since HTML is poorly 
designed, why is it worth preserving?


For the same reasons English is worth preserving.


...
9. Supporters of X/HTML 5 call XHTML 2 radical. History has shown us 
that radical technological change is often controversial, but in the 
end is the best choice. For example, in the last 40 years, the 
technology for delivering music has change radically, from vinyl, to 
cassette, to CD, to purely digital. Why should the Web shy away from a 
radical technological change?

...


For the same reasons people shy away from learning Esperanto. Vinyl, 
cassettes, and CDs are not languages.


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

Re: [whatwg] several messages about HTML5

[James Graham]

Vlad Alexander (xhtml.com) wrote:

4. One of the biggest problems with HTML is that content authors can
get away with writing "tag soup". As a result, most content authors
don't feel the need to write markup to specification. When markup is
not written to specification, CSS may not get applied correctly,
JavaScript may not execute and some user-agents may not be able to
process content as the author intended. Why not put an end to "tag
soup" by requiring user-agents to only accept markup written to
specification?


Because there's a logical gap in the argument that requiring XML-style 
fatal error handling will cause documents to become well formed. That 
hole is simply the assumption that authors would choose to use such a 
document format when competing formats with graceful error handling are 
available. Witness the fact that despite the supposed benefits of XML 
the number of websites that are ever fed through a XML parser is 
miniscule; the vast majority of "XHTML" sites on the web would not 
actually work if the error handling requirement was based on doctype 
rather than MIME type. I suggest that if authors of these sites actually 
had to consistently produce well formed (not even valid!) content, they 
would quickly return to HTML -- otherwise why are they not reaping the 
"benefits" of XML by sending application/xhtml+xml to browsers which 
support it? Indeed I believe that it is _only_ because of the lax error 
handling that the web has caught on to the extent that it has; the 
people with interesting content are often not those with a fanatical 
devotion to computer language syntax.


Even in cases where the content really is well formed XML the client is 
entirely the wrong place to enforce validity -- it means that a tiny 
mistake causes suffering for the person least able to deal with the 
problem -- the end user. Needless to say this is terrible UI and thus 
widespread implementation of fatal error handling is, at best, a 
metastable situation -- as soon as one UA decides they can gain some 
advantage by including error handling, everyone else has to follow suit. 
This has happened with many "XML" based feed formats, for example.


Compared with these issues, the problems with tag soup that you bring up 
are much less substantial. Even with identical parsers in all browsers 
differences between UA's CSS and DOM implementations will still cause 
rendering and scripting differences and thus authors will still need to 
ensure that the content works acceptably across a range of browsers. No 
doubt using a conformance checker to locate syntax errors (which is, of 
course, the correct place to perform such a check -- where the problem 
can be fixed) will still be an important part of this debugging process.


By offering a well-defined algorithm for handling syntax errors, HTML5 
offers a future with significantly less ambiguity in the behavior of 
browsers when they encounter poor markup, thus bringing the benefits 
that consistency offers without the user hostile and, I believe, 
unworkable, XML approach of taking home the ball and refusing to play.



6. The font element is a terrible construct, primarily because
content creators using authoring tools use the font element instead
of semantic markup.


People also use  and  instead of semantic markup. 
Semantically  is no worse than . Neither are ideal 
but the experience of WYSIWYG editor implementors is that it is 
impossible to design a WYSIWYG editor that produces good semantic markup 
all the time and is usable by the kind of person who wants to use a 
WYSIWYG editor. This is an example of "practicality beats purity" a 
tenant of the Python programming language which I believe also applies 
to much HTML5 work (perhaps others would disagree; obviously I only 
speak for myself).



10. In the minds of most people.  HTML is dead and X/HTML 5 is

> perceived as an attempt to resurrect it.

Do you have some statistics on that? It's certainly not what I perceive 
(I do believe that many people use "XHTML" in a cargo-cultish way 
because they have been told it is "better" but without understanding 
why). Furthermore, the reformation of the html working group at W3C 
suggests they don't believe html is dead. In the absence of supporting 
evidence, may I suggest your statement could be interpreted as trolling, 
which I assume was not intended.



 Given this perception, how
can you succeed in marketing HTML to consumers (those who build Web
sites)?


By providing features they want to use. This is already happening -- 
see, for example, the use of  in several places, the fact that 
Opera supports Web Forms 2 (amongst other parts of HTML5), the fact that 
Firefox now has support for the offline storage (again, amonst other 
parts of the spec) and so on.




--
"The universe doesn't care what you believe. The wonderful thing about
science is that it doesn't ask for your faith, it just asks for your
eyes" --- http://xkcd.com/c154.html

Re: [whatwg] several messages about HTML5

[Benjamin Hawkes-Lewis]

Vlad Alexander (xhtml.com) wrote:

(NB I'm just another correspondent, not an official WHATWG voice or
anything.)

> Why not put an end to "tag soup" by requiring user-agents to only
> accept markup written to specification?

Problem 1: Even if HTML5 were /not/ intended to be backwards compatible,
would browser developers implement such a specification, even were the
specification precise enough that algorithms could distinguish "markup
written to specification" from (say) valid, well-formed gibberish?

Problem 2: HTML5 is intended to define a parsing model that can cope
with the majority of existing text/html content. Very little of that
conforms to any specification; a great deal of it is "tag soup".

> 5. X/HTML 5 has a construct for adding additional semantics to
> existing elements using predefined class names. Predefined class names
> could be the most controversial part of X/HTML 5, because the
> implementation overloads the class attribute. XHTML 2 provides similar
> functionality using the role attribute. Which approach is better and
> why?

I keep trying to wrestle with this question. Neither is great. Both
roles and microformats promise to be extension mechanisms, but neither
(AFAICT) includes a reliable mechanism for defining default behaviour or
style. When you mark up a heading with  you can reliably expect user
agents to expose that information ("this is a heading") to end users. No
such expectation is possible with microformats or roles. They are thus
architecturally best suited for machine processing and as style hooks,
not to be considered as genuine additions to the standard set of
elements and attributes (compare the HTML 4.01 spec's discussion of the
class attribute).

A major exception to this rule will be any microformats or roles
referenced from the Web Applications 1.0 or XHTML2 specifications
themselves, because there we should be able to count on user agent
support. In the case of XHTML2, this includes not only the rather vague
roles defined in the role module but more importantly the WAI roles that
are actually being implemented by Mozilla (and related AT such as
Window-Eyes, JAWS, and NVDA).

I suppose whether you think microformats are better than roles depends
on (among other factors):

1) Whether you think a central repository of human-readable definitions
(currently the WHATWG wiki) or human-readable definitions supplemented
by RDF available from decentralized repositories that are not
necessarily referenced from documents are the best ways of defining the
new semantics.

2) Whether you think being able to use the semantics in text/html is
important. (You can express some roles in text/html but not combined in
certain ways.)

3. Whether you think any putative benefits of roles as an extension
mechanism (rather than an accessibility enhancement) justify replacing
microformats, an existing system that (kind of) works.

> 6. The font element is a terrible construct, primarily because content
> creators using authoring tools use the font element instead of
> semantic markup. The X/HTML 5 spec supports the font element when
> content is authored using WYSIWYG editors. What is the rationale for
> this?

I think  should be jettisoned myself, but it does help prevent
misuse of semantic elements for presentational purposes.

>  Why would WYSIWYG editors get an exemption? 

Because anybody generating HTML /should/ know better.

> And is this exemption going to make the Web less accessible?

Mixing in presentational information with semantic information /tends/
to decrease accessibility, but not as much as semantic misinformation.
So it's hard to say. At least with  it's still text. What we need
is new authoring tools that dump the broken WYSIWYG model, more than new
specifications.

> 7. The XHTML 5 spec says that "generally speaking, authors are
> discouraged from trying to use XML on the Web". Why write an XML spec
> like XHTML 5 and then discourage authors from using it? 

Well, one reason would be that popular and old browsers, and hence AT,
don't support XHTML, and newer/better browsers don't support it as well
as they do text/html. Of course, this reason will be half neutralized if
the backwards compatibility of XHTML5 turns out to be mostly phantom.
I've always found the idea (occasionally floated on this list) of
defining a reliable subset of HTML 4.01 with a better defined parsing
model rather attractive for this reason. It could then be used as a
target for transformations.

> Why not just drop support for XML (XHTML 5)?

Well a key motivation is that some authors prefer using XHTML.

--
Benjamin Hawkes-Lewis

Re: [whatwg] several messages about HTML5

[Rimantas Liubertas]

<...>

10. In the minds of most people, HTML is dead and X/HTML 5 is perceived as an 
attempt to resurrect it. Given this perception, how can you succeed in 
marketing HTML to consumers (those who build Web sites)?


Aren't those minds of the people who sell XHTML tools with false
statements like "This is because only XHTML Strict and 1.1 guarantee
the clean separation of data from formatting, making them the clear
choice whenever availability of data is an important factor."?


From what I see around most people don't really care is it XHTML, HTML

or FOOBARML, as long as it works. Some of those who do realize that
HTML4.01 might be better idea than XHTML processed by HTML parser...

HTML5 might be very appealing excatly because it is as close to the
"real world" (tm) as possible.


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

Re: [whatwg] several messages about HTML5

[Vlad Alexander (xhtml.com)]

4. One of the biggest problems with HTML is that content authors can get away 
with writing "tag soup". As a result, most content authors don't feel the need 
to write markup to specification. When markup is not written to specification, 
CSS may not get applied correctly, JavaScript may not execute and some 
user-agents may not be able to process content as the author intended. Why not 
put an end to "tag soup" by requiring user-agents to only accept markup written 
to specification?

5. X/HTML 5 has a construct for adding additional semantics to existing 
elements using predefined class names. Predefined class names could be the most 
controversial part of X/HTML 5, because the implementation overloads the class 
attribute. XHTML 2 provides similar functionality using the role attribute. 
Which approach is better and why?

6. The font element is a terrible construct, primarily because content creators 
using authoring tools use the font element instead of semantic markup. The 
X/HTML 5 spec supports the font element when content is authored using WYSIWYG 
editors. What is the rationale for this? Why would WYSIWYG editors get an 
exemption? And is this exemption going to make the Web less accessible?

7. The XHTML 5 spec says that "generally speaking, authors are discouraged from 
trying to use XML on the Web". Why write an XML spec like XHTML 5 and then 
discourage authors from using it? Why not just drop support for XML (XHTML 5)?

8. The chair of the HTML Working Group at W3C, Steven Pemberton, said "HTML is 
a mess!" and "rather than being designed, HTML just grew, by different people 
just adding stuff to it". Since HTML is poorly designed, why is it worth 
preserving? Or is HTML fixable? If so, how does X/HTML 5 fix it?


9. Supporters of X/HTML 5 call XHTML 2 radical. History has shown us that 
radical technological change is often controversial, but in the end is the best 
choice. For example, in the last 40 years, the technology for delivering music 
has change radically, from vinyl, to cassette, to CD, to purely digital. Why 
should the Web shy away from a radical technological change?


10. In the minds of most people, HTML is dead and X/HTML 5 is perceived as an 
attempt to resurrect it. Given this perception, how can you succeed in 
marketing HTML to consumers (those who build Web sites)?

Re: [whatwg] several messages about HTML5

[Ian Hickson]

On Mon, 19 Feb 2007, Vlad Alexander (xhtml.com) wrote:
>
> Why do we need X/HTML 5? When did this need become apparent?

HTML started as a document language for scientist to share their
work. It evolved over time; for example the  element was added,
forms were added, WYSIWYG features were added, and then removed in
favour of CSS, and so forth. In the last few years, the Web has
evolved yet again, reaching a much more dynamic state than it had
before (pundits refer to this as "Web 2.0"). The HTML5 effort is about
maintaining and evolving HTML5 to address the needs of 21st century
Web authors.

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


> X/HTML 5 is currently in Working Draft stage. What is the tentative 
> timetable for moving X/HTML 5 through the standards approval process 
> towards Recommendation stage?

We're trying a new spec design model with HTML5, where certain parts
of the spec can be considered "done" before others. This is because we
have parts of the spec that are very mature, with multiple
implementations, test suites, and active use, and we have others that
are very new, and very much in flux.

Right now this isn't very obvious; members of the community are
working on a system that will annotate the spec live, though, so you
can see what parts are stable are what parts are not. Other members of
the community have also worked on a page that lets you pick what
changes to the spec you want to see, so that you can, say, only see
changes to stable parts of the spec that affect Firefox.

   http://html5.org/tools/specification-diff

All this makes it hard to give a real timetable. Some parts of the
spec are already done and actively used -- for example Yahoo! Pipes
makes use of the  feature of HTML5. Historically, the point at
which specifications have been branded Recommendations has been
somewhat arbitrary. For example, HTML4, which reached the
Recommendation stage in the late 90s, is still being developed and
fixed. Not all parts of HTML4 are implemented in browsers, some parts
of HTML4 are known to be wrong but have no errata, and so forth. A big
part of the work on HTML5 is actually just fixing HTML4 problems.

HTML5 is being developed completely in the open, by the way. Anyone
can take part. See http://www.whatwg.org/ for links to our forums, IRC
channel, blog, FAQ, wiki, mailing lists, etc.


> X/HTML 5 introduces new markup constructs such as sectioning elements, 
> enhancements to the input element, a construct for dialogs, a way to 
> mark up figures, and much more. Can you briefly describe these new 
> constructs and the reason they were added?

We're trying to use a much more scientific process with the
development of HTML5 than is usually used for new specifications. So,
for example, many of the new sectioning elements (for marking up
navigation blocks, articles, sections, footers, headers, and so forth)
were based on a study of several billion documents done by Google,
where we saw that these were the sectioning elements most used by
authors.

   http://code.google.com/webstats/

Some of the other features, like the scoped stylesheet feature that
allows