Re: [whatwg] Authoring Re: several messages about HTML5

[Andrew Fedoniouk]

- Original Message - 
From: "Adrian Sutton" <[EMAIL PROTECTED]>

To: "Karl Dubost" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, February 21, 2007 6:45 PM
Subject: Re: [whatwg] Authoring Re: several messages about HTML5



Did you notice in your development of an WYSIWYG HTML editor things
from the specification that
- were very difficult to implement?




In terms of what is difficult to implement - lists and tables, but I'm
not sure that's because of the HTML format. Lists and tables are just
hard to get right in the first place (even Word's list support is
regularly infuriating). In general I don't find that the back-end format
matters that much in editing, you just need to parse it into a model
that is suitable for an editor. I would hate to have to implement an
editor based around a standard DOM model of the HTML document because
the user doesn't view the document as a tree - they view it as a string
of text. So the model used when editing needs to be more like a string
of text than a tree.




I agree that HTML DOM is not suitable for WYSIWYG editing.
Especially in presence of CSS on top of it.
HTML/CSS rendering (direct) task is pretty much formalized currently.
But WYSIWYG editing is aiming to solve inverse problem - by 
having image on screen (or intention to have one) it needs to
build underlying DOM/CSS. And that task in presence of 
CSS has no unambiguous solution mathematically speaking - 
exactly same rendering (image) can be produced by various 
combinations of HTML/CSS markup/rules.


As for illustration to Adrian's comments:

This markup:

---start--

  one
  two

---end---

will be rendered as 


---start--

* one
* two

---end---

There are margins on top and bottom of the list.
Problem is that it is *very* hard to visualize what
part of what element is participating in formation
of the spacing between the lines.

For WYSIWYG editing purposes the DOM needs
to be flattened to something like this:
---start--
one
two
---end---

Otherwise any WYSIWYG editor shall have 
1) sidebar with the text of the "8.3.1 Collapsing margins" [1]

  and around.
2) shall have so called "source view".

Last version of HTML that allow frustration-less 
WYSIWYG editing was pure v.3.2 I believe. 


Practically speaking:  or something
suitable for WYSIWYG on the web shall use 
some simplified markup (flat DOM).  
Markup like "bbcodes" or "wikicodes" is a good 
example of such practical formats.


Andrew Fedoniouk.
http://terrainformatica.com

[1] http://www.w3.org/TR/CSS21/box.html#collapsing-margins

Re: [whatwg] Authoring Re: several messages about HTML5

[Adrian Sutton]

> Did you notice in your development of an WYSIWYG HTML editor things
> from the specification that
>   - were very difficult to implement?
>   - were missing in the HTML language itself to make it easier to
> control the editing?

There are a couple of things to note here. Firstly our editor is written
in Java, not JavaScript so the second question doesn't really apply
because we're not limited to what can be done in HTML and JavaScript.
The only real problem we've seen in terms of HTML limitations for
implementing the editor is a lack of granularity in terms of
contenteditable. There is some demand to be able to specify an
uneditable template to use within the editor and have users fill in
and/or edit specific parts of it. Unfortunately there are a number of
situations where the editability is ambiguous such as:

* when an uneditable element is at the end of the document - is the user
allowed to insert another element after it?
* when there is an editable paragraph inside an uneditable block, is the
user allowed to break the paragraph in two? Can they insert another
paragraph after the editable paragraph?

In terms of what is difficult to implement - lists and tables, but I'm
not sure that's because of the HTML format. Lists and tables are just
hard to get right in the first place (even Word's list support is
regularly infuriating). In general I don't find that the back-end format
matters that much in editing, you just need to parse it into a model
that is suitable for an editor. I would hate to have to implement an
editor based around a standard DOM model of the HTML document because
the user doesn't view the document as a tree - they view it as a string
of text. So the model used when editing needs to be more like a string
of text than a tree.

> Bonus question:
>   Do you think that there are needs outside of HTML itself, but
> needed
> for authoring HTML, and would need to be shared among an authoring
> tools community?

Nothing that immediately comes to mind, but I'm subscribed here to lurk
and provide the perspective of an editor maker where appropriate so as
things come up I'll be sure to chime in.

> Karl Dubost - http://www.w3.org/People/karl/

Regards,

Adrian Sutton.

Re: [whatwg] Geolocation in the browser

[Ryan Sarver]

Robert,

I hear you ... the idea is really two fold -- the first part is to standardize 
how web applications access the location information, regardless of how it is 
determined. The second is to offer a standard way of different location 
acquiring technologies -- GPS, Wifi positioning, geocoding an user-entered 
address, etc -- to deliver location to the browser. In this case I am proposing 
using the NMEA standard as it is well documented and would allow for 
compatibility with existing GPS devices.

I agree, there are very few GPS-enabled laptops - in fact the only one I know 
if us a UMPC - but there are a lot of Bluetooth capable laptops and Bluetooth 
antennas to provide the location. There are also solutions like ours at Skyhook 
that are software-only and would allow people to immediately begin to provide 
their location to the browser via a simple download.

This would all obviously be configurable in the UA...

-Original Message-
From: Robert Accettura [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 8:29 PM
To: Ryan Sarver
Cc: Steve Runyon; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Geolocation in the browser

Ryan Sarver wrote:
>
> Steve, good points…
>
>  
>
> It’s also important to remember that this functionality would be an 
> opt-in system – unlike your cell phone :) The prototype that we are 
> working on would allow the browser to point to a COM port where it 
> could find a GPS device or any NMEA-compatible device or software. It 
> would then read the NMEA stream over the COM port and use that to 
> deliver the user’s location to the website via the DOM.
>
>  
>
> Our software positions you based on WiFi triangulation and can emulate 
> a GPS device by streaming NMEA over  a virtual COM port so that the 
> user wouldn’t need to have a dedicated GPS antennae.
>
I'd think a more practical approach would be to allow for a user-entered 
location, and let GPS override should the user have a GPS capable device.  
There are many good reasons to to have geolocation (statistical, custom 
content, etc.), but few GPS capable devices.  I think more content providers 
would consider this to be a usable source of data if the UA had fallbacks (GPS, 
OS, preference in UA). 

--
Robert Accettura
[EMAIL PROTECTED]

Re: [whatwg] Geolocation in the browser

[Robert Accettura]

Ryan Sarver wrote:
>
> Steve, good points…
>
>  
>
> It’s also important to remember that this functionality would be an
> opt-in system – unlike your cell phone :) The prototype that we are
> working on would allow the browser to point to a COM port where it
> could find a GPS device or any NMEA-compatible device or software. It
> would then read the NMEA stream over the COM port and use that to
> deliver the user’s location to the website via the DOM.
>
>  
>
> Our software positions you based on WiFi triangulation and can emulate
> a GPS device by streaming NMEA over  a virtual COM port so that the
> user wouldn’t need to have a dedicated GPS antennae.
>
I'd think a more practical approach would be to allow for a user-entered
location, and let GPS override should the user have a GPS capable
device.  There are many good reasons to to have geolocation
(statistical, custom content, etc.), but few GPS capable devices.  I
think more content providers would consider this to be a usable source
of data if the UA had fallbacks (GPS, OS, preference in UA). 

-- 
Robert Accettura
[EMAIL PROTECTED]

begin:vcard
fn:Robert Accettura
n:Accettura;Robert
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard



smime.p7s
Description: S/MIME Cryptographic Signature

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/

[whatwg] Private class names (was: "several messages about HTML5")

[Michel Fortin]

Le 2007-02-21 à 16:58, Elliotte Harold a écrit :


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 -?


That could also work, but based on aesthetics I still prefer my first  
proposal.


You are here

.x-superparagraph { font-size: 90% }


You are here

.-superparagraph { font-size: 90% }



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


It seems to me that the current spec allows itself to define any  
class name as its own while still allowing authors to use any yet- 
undefined ones. Are you suggesting that the spec disallows the use of  
undefined class names starting with "html-"? What would be the purpose?



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

Re: [whatwg] Authoring Re: several messages about HTML5

[Karl Dubost]

Hi adrian,

Le 22 févr. 2007 à 07:15, Adrian Sutton a écrit :
As someone who writes a WYSIWYG HTML editor for a living - I wish  
you the very best of luck, you're going to need it. Writing an  
editor is one of those problems that seems really easy until you  
get into it, then it starts looking hard.


Did you notice in your development of an WYSIWYG HTML editor things  
from the specification that

- were very difficult to implement?
	- were missing in the HTML language itself to make it easier to  
control the editing?


Bonus question:
	Do you think that there are needs outside of HTML itself, but needed  
for authoring HTML, and would need to be shared among an authoring  
tools community?




--
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] Authoring Re: several messages about HTML5

[Adrian Sutton]

> I am therefore devoting a lot of my time into developing a
> new kind of authoring environment that combines a semantic view with
> a wysiwyg view, and which will use dictionaries to generate the
> markup that few of us can be bothered to write directly.

As someone who writes a WYSIWYG HTML editor for a living - I wish you the very 
best of luck, you're going to need it. Writing an editor is one of those 
problems that seems really easy until you get into it, then it starts looking 
hard. You get through that and ship it to users and they love it and you pat 
yourself on the back. After about six months of solid usage users have worked 
with the editor enough to start getting frustrated about its quirks, 
limitations and bugs and the complaints start pouring in. Then you *really* 
understand how big the challenge is.

I don't say that to deter you - I'm actually very keen to see what you come up 
with. The main message to take out of this is that you have to pay attention to 
and get right the very smallest details because they all make a very big 
difference to users. When people get into writing they want to focus purely on 
what they are writing and they don't want to have to think for a second about 
how the authoring tool they are using wants them to work. If you want the tool 
to succeed you will need to solve the keyboard shortcut problems - they are 
vital, you will also need to make sure that whatever interface you come up with 
to try and get users to create semantic mark up doesn't require them to think 
about it. If you haven't already, you will come to learn that users think 
visually and they are and probably will always be more interested in their 
content looking good right there in front of them than on it being all nice and 
semantic. To succeed you will need to leverage this by making the content look 
best right there in front of them when it is semantic.

You also need to realize that users are very, very picky. Expect to devote many 
years reviewing and refining the basic functionality of your editor - stick to 
the minimum of functionality and get it into the hands of real users doing real 
work as much as possible. Then use the feedback from them (carefully because 
they will change their views after using the tool for a period of time) to 
drive new features and improvements to the way the editor works.

Best of luck with it. I'm definitely interested in keeping track of the project.

Regards,

Adrian Sutton. 

Re: [whatwg] Geolocation in the browser

[Ryan Sarver]

Steve, good points...

 

It's also important to remember that this functionality would be an opt-in 
system - unlike your cell phone :) The prototype that we are working on would 
allow the browser to point to a COM port where it could find a GPS device or 
any NMEA-compatible device or software. It would then read the NMEA stream over 
the COM port and use that to deliver the user's location to the website via the 
DOM.

 

Our software positions you based on WiFi triangulation and can emulate a GPS 
device by streaming NMEA over  a virtual COM port so that the user wouldn't 
need to have a dedicated GPS antennae.

 

From: Steve Runyon [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 4:48 PM
To: Ryan Sarver
Subject: Re: [whatwg] Geolocation in the browser

 

Makes sense to me.  And while the privacy issues that others have brought up 
are real, it does seem doable to make it user-configurable.  Perhaps the first 
time the user hits a site that wants to know where they are they have the 
more-or-less standard "disallow/allow this time/always allow" options?  

 

And as with cell phones (which in the US at least must include location info 
when the user dials 911 for help), there should be reasonable guarantees that 
intelligence agencies and law enforcement can't activate the locator 
unbeknownst to the user without a search warrant. 

 

On 2/21/07, Ryan Sarver <[EMAIL PROTECTED]> wrote: 

That's a good point. I think you're right that the "navigator" object might 
make more sense:

 

// Example

var location = navigator.getLocation()

alert(location.latitude+', '+location.longitude);

 

thoughts?

 

From: Steve Runyon [mailto:[EMAIL PROTECTED] ] 
Sent: Wednesday, February 21, 2007 4:27 PM
To: Ryan Sarver
Subject: Re: [whatwg] Geolocation in the browser

 

You couldn't use window.location because that's already used:  "the location 
object represents information about the URL of any currently open window or of 
a specific frame" (Danny Goodman, JavaScript Bible 4e, p 486).  How about the 
navigator object? 



 

On 2/21/07, Ryan Sarver <[EMAIL PROTECTED]> wrote: 

David,

The ICBM standard is for geotagging the actual content whereas we are talking 
about a standard that lets the content know the location of the User or device 
so that the website can be location-aware. 

I want to use as much of the existing standards, but have more questions about 
where it should exist in ecosystem and how servers and webpages would expect to 
see it and use it.

-Original Message-
From: David Latapie [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 3:56 PM
To: Ryan Sarver 
Cc: whatwg@lists.whatwg.org 
Subject: Re: [whatwg] Geolocation in the browser

On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote: 
>  - would it make sense to also expose it in the request headers? This
> way the server receives it on the first request as opposed to through 
> the client after the initial page request
>
> 
>
> User-Geolocation: 43.338018, -71.817930

Surely you've heard of ICBM
()

Could elaborate on what you like and dislike on this? 
--
 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

[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] Authoring Re: several messages about HTML5

[Sander Tekelenburg]

At 16:18 +0200 UTC, on 2007-02-21, Henri Sivonen wrote:

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

[...]

>> 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.

Absolutely, yes.  provides some arguments. But
obviously listing arguments is not the same as convincing people. Having some
proofs of concept, and thus be able to actually demonstrate the advantages,
will make it easier to convince people.

>> 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.

I understand what you mean. I put "natural" in quotes because it's not the
best description of what I mean: right now we have editors that for instance
require people to decide whether to mark smething up as a heading or as bold.
An editor on the other hand that allows only blocks to be defined as heading,
and only inline content as important, by providing only options that are
relevant to the context, shields people from having to make such too
difficult technical choices. That's what I meant with "natural": making
things simpler for people.

>> 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?

Yes. The Web Repair Initiative is working on getting funding and form a
'core', a consortium of a few parties which will produce actual code/tools[1]
(we have one party aboard that is doing that already right now). This core is
to be a basis for a broader community effort to amongst other things help
authoring tool authors who want to produce better output but need help. We
aim to be a 'central point' where authoring developers can get help with
this, both by offering them tools and code snippets they can integrate in
their product, and by sharing experience on how to solve specific problems.
And of course last but not least, by providing a specification[2] of what
exactly their authoring tools need to provide. (That specification is to be
defined through an open process, just like WHATWG does here.)


[1]  and its sub pages.
[2] 


-- 
Sander Tekelenburg
The Web Repair Initiative: 

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] Geolocation in the browser

[Ryan Sarver]

That's a good point. I think you're right that the "navigator" object might 
make more sense:

 

// Example

var location = navigator.getLocation()

alert(location.latitude+', '+location.longitude);

 

thoughts?

 

From: Steve Runyon [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 4:27 PM
To: Ryan Sarver
Subject: Re: [whatwg] Geolocation in the browser

 

You couldn't use window.location because that's already used:  "the location 
object represents information about the URL of any currently open window or of 
a specific frame" (Danny Goodman, JavaScript Bible 4e, p 486).  How about the 
navigator object? 



 

On 2/21/07, Ryan Sarver <[EMAIL PROTECTED]> wrote: 

David,

The ICBM standard is for geotagging the actual content whereas we are talking 
about a standard that lets the content know the location of the User or device 
so that the website can be location-aware. 

I want to use as much of the existing standards, but have more questions about 
where it should exist in ecosystem and how servers and webpages would expect to 
see it and use it.

-Original Message-
From: David Latapie [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 3:56 PM
To: Ryan Sarver
Cc: whatwg@lists.whatwg.org 
Subject: Re: [whatwg] Geolocation in the browser

On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote:
>  - would it make sense to also expose it in the request headers? This
> way the server receives it on the first request as opposed to through 
> the client after the initial page request
>
>
>
> User-Geolocation: 43.338018, -71.817930

Surely you've heard of ICBM
()

Could elaborate on what you like and dislike on this?
--
 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

[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] Geolocation in the browser

[Ryan Sarver]

There are obvious privacy concerns -- I feel they can be alleviated with
the proper level of control for the user. Currently in our prototypes,
the browser prompts the user for each request, which they can allow or
deny and then remember that preference for subsequent requests from that
domain. What type of privacy control are you envisioning?

As for a user-interface problem, its not much different than the
allowing / blocking of popups on a per-domain basis. There are
definitely existing standards to piggy-back ontop of in terms of UI
controls and dialogs.


-Original Message-
From: Henri Sivonen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 4:24 PM
To: Ryan Sarver
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Geolocation in the browser

On Feb 21, 2007, at 22:31, Ryan Sarver wrote:

> What are people's thoughts on location in the browser?

My first thought is that it is a privacy problem. And per-site  
configurability of the exposure of location data is a user interface  
problem.

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

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] Geolocation in the browser

[Henri Sivonen]

On Feb 21, 2007, at 22:31, Ryan Sarver wrote:


What are people’s thoughts on location in the browser?


My first thought is that it is a privacy problem. And per-site  
configurability of the exposure of location data is a user interface  
problem.


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

Re: [whatwg] Authoring Re: several messages about HTML5

[Sander Tekelenburg]

At 09:29 + UTC, on 2007-02-21, James Graham wrote:

[...]

> 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.

It depends on which types of authoring tools you look at. Tools like
Dreamweaver are geared more towards design, and thus used by people who care
more about looks than about semantics. But within a larger organisation,
you're more likely to have a CMS where many different people need to simply
enter/edit content, without dealing with presentational aspects. In such
situations it would be a benefit if people aren't  bothered with having to
make design decisions. Just let them enter the content and describe its
structure/meaning. (This seems somewhat comparable to databases, where people
are forced to enter data in a specific structured form, without having to
deal with the underlying magic.)

Such an approach can make things easier for both those who enter content and
those who are in charge of suggesting a presention of that content. The whole
publication process becomes more managable. I think that's a benefit that
will be recognised.


-- 
Sander Tekelenburg
The Web Repair Initiative: 

Re: [whatwg] Geolocation in the browser

[Ryan Sarver]

David,

The ICBM standard is for geotagging the actual content whereas we are talking 
about a standard that lets the content know the location of the User or device 
so that the website can be location-aware.

I want to use as much of the existing standards, but have more questions about 
where it should exist in ecosystem and how servers and webpages would expect to 
see it and use it.

-Original Message-
From: David Latapie [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 3:56 PM
To: Ryan Sarver
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Geolocation in the browser

On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote:
>  - would it make sense to also expose it in the request headers? This
> way the server receives it on the first request as opposed to through
> the client after the initial page request
> 
>  
> 
> User-Geolocation: 43.338018, -71.817930

Surely you've heard of ICBM
()

Could elaborate on what you like and dislike on this?
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] Geolocation in the browser

[David Latapie]

On Wed, 21 Feb 2007 15:31:11 -0500, Ryan Sarver wrote:
>  - would it make sense to also expose it in the request headers? This
> way the server receives it on the first request as opposed to through
> the client after the initial page request
> 
>  
> 
> User-Geolocation: 43.338018, -71.817930

Surely you've heard of ICBM
()

Could elaborate on what you like and dislike on this?
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

[whatwg] Geolocation in the browser

[Ryan Sarver]

Hey guys. I have been watching the list for a bit and thought it was
time for me to jump in here and kick off a discussion on
geolocation-aware browsing. I tried to search through the archives to
see if the discussion had come up before and didn't find anything, so
please forgive me if it has.

 

I am the Dir of Product Development at Skyhook Wireless where we have a
Wi-Fi Positioning System - think GPS, but software-only and uses
Wireless APs instead of satellites. We have been working on developing a
plugin for Firefox that gives a website access to the user's location
via javascript. User's can control access to this information at the
domain level in much the same way they control cookies and popups.

 

We have been successful in exposing it through the Javascript DOM and
wanted to start talking with standards bodies about coming up with a
standard implementation to make location-aware browsing common
functionality at the browser level. I was hoping to kick off a
discussion around possible implementations and get the community's
thoughts on the topic.

 

Location could be exposed through a standard Javascript object/interface

 

var location = window.getLocation();

 

 - would it make sense to also expose it in the request headers? This
way the server receives it on the first request as opposed to through
the client after the initial page request

 

User-Geolocation: 43.338018, -71.817930

 

What are people's thoughts on location in the browser? Is the "window"
object the right object to attach to? Im interested to hear everyone's
thoughts...

 

Best, Ryan

Re: [whatwg] X/HTML5 and DocBook

[Martin Atkins]

David Latapie wrote:

Hello,

I never used it, but a common complaint about DocBook is that there is 
too much tags.


Now, considering how microformats seems to be the Next Big Thing™ (and 
we are talking quite a lot on this ML about this technology), could 
someone with a background in DocBook tell me (us) how 
X/HTML5+microformats differs from DocBook?


Please remember I may have wrong ideas about DocBook (or about X/HTML5, 
for that matter).




I believe the "Simplified DocBook" DTD was invented to address the 
concern that DocBook was too complicated. I've seen Simplified DocBook 
as an attempt to get an "HTML-like" simplicity while retaining the 
powerful structured nature of DocBook documents.


HTML5 comes at this from the other perspective, to a certain extent: 
while Simplified DocBook scaled down DocBook to be more like HTML, HTML5 
adds structure elements to HTML to make it a bit more like DocBook in 
many respects.


Of course, that's not all HTML5 does. Many of HTML5's new features are 
not for "documents" at all, but rather for web applications.

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] Layout Problem: Floating Elements with different heights breaks the flow.

[Ian Hickson]

On Wed, 21 Feb 2007, Shlomi Asaf wrote:
>
> i have a "table" like layout.
> here is a live example: http://www.webcssdesign.34sp.com/me/floatingDivs.htm

I'm afraid you have posted to a mailing list where we discuss future plans 
for HTML, not where we discuss Web design problems. However, we have a 
separate mailing list for design problems, which you are welcome to join. 
It is [EMAIL PROTECTED] See more information here:

   http://lists.whatwg.org/listinfo.cgi/help-whatwg.org

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

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.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Layout Problem: Floating Elements with different heights breaks the flow.

[Shlomi Asaf]

Hi
i have a "table" like layout.
here is a live example: http://www.webcssdesign.34sp.com/me/floatingDivs.htm

all the floating divs has the same height. i haven't written the height in
the css- the content is the same.
all the titles are one line height.
but what happens when one title is longer? the layout breaks and the lower
float element looks for his position in a the next empty space - after the
high element.

how can i solve this problem?
i can find few suggestion but none of them satisfy me:

  1. an Element with clear:both after each ending line.
  2. a Specific height and a overflow:hidden to the title.
  3. a Table

all those solutions are bed.

  1. clear both hurts the simplistic of the server side work- the server
  side programer will have to count the number of elements in each raw and
  then place the clearing element
  2. the height makes the layout inflexible, and empty space where they
  will be only 1 line title
  3. i don't want to get into that :)

any help will be appreciated

Tnx a Lot
NeoSwf

Re: [whatwg] Definition list and tables: what's the difference ?

[David Latapie]

On Wed, 21 Feb 2007 08:45:14 -0500, Michel Fortin wrote:
> What about nested definition lists like all those found in the HTML5 
> spec? Would you replace them by nested tables or a bizarre 
> organisation of cells using rowspan and colspan? And would it still 
> be intelligible?

Yes and Yes.
Content and subcontent, with relations. CSS shall take care of 
readability quite easily (no border, for instance)

> The difference between a table and a definition list is more akin the 
> difference between a table and a paragraph in my view. The table is 
> mostly about data, the definition list is mostly about text. There 
> are many cases where both could be used as effectively, but there are 
> many others where one makes much more sense than the other.

I don't think one can oppose data and text (no problem for "numbers and 
text"). In the examples you provided, text is data.
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] Authoring Re: several messages about HTML5

[David Latapie]

On Wed, 21 Feb 2007 10:47:50 +0100, Charles McCathieNevile wrote:
> As people got printers and desktop publishing a 
> few people made the crazy multi-font unreadable pages that were all 
> the rage in the mid-80s

Same goes for the newspaper industry for the first part of the 20th 
century
-- 
 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: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] Thoughts on the element (formerly the element).

[David Latapie]

On Mon, 19 Feb 2007 07:51:46 +1100, Lachlan Hunt wrote:
>> | 
>> |   XForms is a W3C recommendation.
>> |   
>> |   XForms Tiny is does not conflict with XForms, but WF2 does.
>> | 
> 
> Interesting.  The concept of specifying who added a particular mark 
> using the |by| attribute could be useful for collaborative 
> editing/reviewing.

I like it too. Maybe some kind of machine-readable ID (like 
"user-45023" or byid="45023") could have some use, once again for 
collaborative editing, the same way as datetime use a machine-readable 
format (-mm-dd). I don't know much on this topic and Friendly name 
should be favoured if they suffice.
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg]

[David Latapie]

On Wed, 21 Feb 2007 14:19:43 +0100, Martijn wrote:
> 2007/2/21, David Latapie <[EMAIL PROTECTED]>:
>> I never understood what  is done for. Is it some kind of
>> precursor of Google Sitemaps?
> 
> http://en.wikipedia.org/wiki/HTML_element
> "
> … (deprecated)
> 
>The :isindex element requires server side support for indexing
> documents. Visually presents a one-line text input for keyword entry.
> When submitted, the query string is appended to the current URL and
> the document is displayed with these keywords highlighted. Generally
> if the server supports this feature it will add the iisindex elements
> to documents without author intervention.
> "
> More info here:
> http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/isindex.html
> http://www.blooberry.com/indexdot/html/tagpages/i/isindex.htm

Thank you. The latest link also says that it was “Dropped in XHTML 1.1 
in favor of other more powerful existing form controls” (which one, I 
don't know, not that I care much about for now -- influenza is my main 
concern for now).
-- 
 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] Input field's hint value

[Anne van Kesteren]

On Wed, 21 Feb 2007 11:28:47 +0100, Wolfram Kriesing  
<[EMAIL PROTECTED]> wrote:

Is there already such a thing?


I think Webkit supports a placeholder="" attribute on  elements  
that does this. Since Web Forms 2 is in a feature freeze it hasn't yet  
been added / rejected. I suppose it might be reconsidered when Web Forms 2  
is merged with the rest of HTML5.



--
Anne van Kesteren

Re: [whatwg] The HTML5 outline algorithm and Selectors

[Anne van Kesteren]

On Wed, 21 Feb 2007 15:51:20 +0100, Henri Sivonen <[EMAIL PROTECTED]> wrote:
Is there any coordination between the WHATWG and CSS WG for allowing  
selector matching based on the outline depth as per the HTML5 outline  
algorithm? Or is there perhaps already a way? (My knowledge of  
developments related to Selectors isn't quite up-to-date.)


There has been some discussion on www-style in relation to counters  
mostly, but no solution has been found so far.



For example, to use CSS3 GCPM bookmarks, one needs to select heading  
based on outline depth:

http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#bookmarks


I suggest you raise that on www-style.


--
Anne van Kesteren

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] The HTML5 outline algorithm and Selectors

[Bjoern Hoehrmann]

* Henri Sivonen wrote:
>Is there any coordination between the WHATWG and CSS WG for allowing  
>selector matching based on the outline depth as per the HTML5 outline  
>algorithm? Or is there perhaps already a way? (My knowledge of  
>developments related to Selectors isn't quite up-to-date.)

No. Consider though that half of the "WHATWG" "members" and other
contributors like Anne are regular members of the CSS Working Group.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[whatwg] The HTML5 outline algorithm and Selectors

[Henri Sivonen]

Is there any coordination between the WHATWG and CSS WG for allowing  
selector matching based on the outline depth as per the HTML5 outline  
algorithm? Or is there perhaps already a way? (My knowledge of  
developments related to Selectors isn't quite up-to-date.)


For example, to use CSS3 GCPM bookmarks, one needs to select heading  
based on outline depth:

http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#bookmarks

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

Re: [whatwg] Authoring Re: several messages about HTML5

[Dave Raggett]

On Wed, 21 Feb 2007, Benjamin Hawkes-Lewis wrote:


Dave Raggett wrote:

I am therefore devoting a lot of my time into developing a
new kind of authoring environment that combines a semantic view with
a wysiwyg view, and which will use dictionaries to generate the
markup that few of us can be bothered to write directly.


This project sounds very interesting, although I'm a bit dubious about
the benefit of a single WYSIWYG view rather than a series of views
presenting how a given document skin would look in different devices
(e.g. mobile view, screen reader view, console view, magnifier view,
desktop view). This would help with the problem Chaals mentioned of
people continuing to view the web as essentially a visual medium. Is
this project of yours a public project? Are there more details about
what you're trying to do somewhere?


The wysiwyg view is for there for the purposes of authoring and 
different style sheets are likely used for different delivery 
contexts. I am very much interested in device independent authoring 
tools as part of larger content management frameworks. The idea of 
being able to combine content with different skins for different 
delivery contexts is very appealing.


The editor project will be released as an open source project, at
least as far as the client side pieces are concerned. It is still
at an early stage but a beta release is expected by late Summer.


Perhaps the best metaphor for the separation of content and styles is
"skinning" or "theming", a concept almost as popularly familiar as
WYSIWIG itself.


indeed!

Daniel Glazman (of nVu fame) pointed out the difficulties of using 
wysiwyg with the final style sheets in a presentation in XTech 2006.
How do you do wysiwyg editing if the style sheet hides the piece you 
are editing? An authoring environment could provide one style sheet 
for wysiwyg editing and a range of style sheets for delivery 
purposes.



Authoring tools need to respect this separation of roles and avoid
burdening people with tasks that are inappropriate to their roles.


Yes I suspect moving away from single view to workflow models 
would help here.


I am organizing a workshop on declarative models of distributed web 
applications (June 5-6, Dublin, Ireland) with the goal of bringing 
people together to discuss the modeling, security and usability 
aspects of future authoring frameworks. Some details can be

found here:

  http://www.w3.org/2006/10/uwa-charter.html#workshops

A call for participation will be announced shortly.

Getting back to HTML5, I am interested in a clean way to set an 
editing caret within a document's markup, and independent of the 
existing designMode/contentEditable/execCommand features. In my work 
I am using a span element for the caret and manipulating it via the 
DOM. That works pretty well modulo browser variations for where they 
break lines. It would be good to have fine control of that too, e.g. 
to prevent line breaking within words (except after hyphens) and 
before or after span elements except when adjacent to whitespace.


The designMode/execCommand features in IE and copied by other 
browsers are much to much oriented towards very simple word 
processing (e.g. wordpad) and a poor match to the needs for editing 
structured documents. Furthermore the markup generated varies 
considerably across browsers, though this can be cleaned up to some 
extent via post processing. HTML5 should include support for 
editing, but I would strong recomend against standardizing 
designMode and execCommand in their current form.


 Dave Raggett <[EMAIL PROTECTED]> http://www.w3.org/People/Raggett

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] Input field's hint value

[Dean Edwards]

Alexey Feldgendler wrote:
On Wed, 21 Feb 2007 11:28:47 +0100, Wolfram Kriesing <[EMAIL PROTECTED]> 
wrote:

I was searching, but didnt find a hint-attribute for an input. The
more often we are using inline editing, the more the need for the
following is rising, imho:

From the semantic standpoint, I believe this is what the title attribute 

expresses.

Please somebody correct me if I'm wrong, but this behavior (show the value of 
the title attribute whenever the control is not focused and has empty value) can 
already be specified with CSS over WF2. 



You're right. A hint attribute was discussed but the general feeling 
was that the title attribute was appropriate for this.


-dean

Re: [whatwg] Authoring Re: several messages about HTML5

[Benjamin Hawkes-Lewis]

Dave Raggett wrote:
> I am therefore devoting a lot of my time into developing a 
> new kind of authoring environment that combines a semantic view with 
> a wysiwyg view, and which will use dictionaries to generate the 
> markup that few of us can be bothered to write directly.

This project sounds very interesting, although I'm a bit dubious about
the benefit of a single WYSIWYG view rather than a series of views
presenting how a given document skin would look in different devices
(e.g. mobile view, screen reader view, console view, magnifier view,
desktop view). This would help with the problem Chaals mentioned of
people continuing to view the web as essentially a visual medium. Is
this project of yours a public project? Are there more details about
what you're trying to do somewhere?

Perhaps the best metaphor for the separation of content and styles is
"skinning" or "theming", a concept almost as popularly familiar as
WYSIWIG itself.

> Authoring tools need to respect this separation of roles and avoid
> burdening people with tasks that are inappropriate to their roles.

Yes I suspect moving away from single view to workflow models would help
here.

--
Benjamin Hawkes-Lewis

Re: [whatwg] Definition list and tables: what's the difference ?

[Michel Fortin]

What about nested definition lists like all those found in the HTML5  
spec? Would you replace them by nested tables or a bizarre  
organisation of cells using rowspan and colspan? And would it still  
be intelligible?


Here are two examples:




The difference between a table and a definition list is more akin the  
difference between a table and a paragraph in my view. The table is  
mostly about data, the definition list is mostly about text. There  
are many cases where both could be used as effectively, but there are  
many others where one makes much more sense than the other.



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

Re: [whatwg]

[Martijn]

2007/2/21, David Latapie <[EMAIL PROTECTED]>:

I never understood what  is done for. Is it some kind of
precursor of Google Sitemaps?


http://en.wikipedia.org/wiki/HTML_element
"
… (deprecated)

   The :isindex element requires server side support for indexing
documents. Visually presents a one-line text input for keyword entry.
When submitted, the query string is appended to the current URL and
the document is displayed with these keywords highlighted. Generally
if the server supports this feature it will add the iisindex elements
to documents without author intervention.
"
More info here:
http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/isindex.html
http://www.blooberry.com/indexdot/html/tagpages/i/isindex.htm


Regards,
Martijn

Re: [whatwg] New markup constructs

[David Latapie]

On Tue, 20 Feb 2007 09:30:59 +, Gervase Markham wrote:
> James Graham wrote:
>> [1] http://code.google.com/webstats/2005-12/classes.html
> 
> What a useful URL.

I second you on this. For those who did not follow the link, it shows:
“Which class names are used on the most pages? Here are the top 20:”

and this is compared to the microformats.
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg]

[David Latapie]

On Tue, 20 Feb 2007 10:56:05 +0100, Anne van Kesteren wrote:
> On Tue, 20 Feb 2007 10:52:12 +0100, Alexey Feldgendler 
>> Are there any real-world uses of  remaining? Is this 
>> element worth the trouble?
> 
> Yes. And it's not much trouble...

I never understood what  is done for. Is it some kind of 
precursor of Google Sitemaps?
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] Definition list and tables: what's the difference ?

[David Håsäther]

On Fri, 16 Feb 2007 06:13:25 +0100, David Latapie <[EMAIL PROTECTED]>  
wrote:



Accessorily, I believe there is a need for an equivalent of  for
.  marks a term to define, but what is the marker for its
definition?


"The paragraph, description list group, or section that contains the dfn  
element contains the definition for the term given by the contents of the  
dfn element."

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

--
David Håsäther

Re: [whatwg] Definition list and tables: what's the difference ?

[David Latapie]

On Tue, 13 Feb 2007 15:52:23 +0100, Alexey Feldgendler wrote:
> On Tue, 13 Feb 2007 15:40:13 +0100, David Latapie <[EMAIL PROTECTED]> wrote:
> 
>> My humble point:  can do everything  can, whilst the reverse
>> is not true. He who can do more can do less.
> 
>  canot do this:
> 
> 
> computer
> An electronic device for information processing.
> driver
> A computer program taking care of direct communication with a 
> peripherial 
> device.
> A person who drives a vehicle.
> 
> 
> How would you represent this in a  without abusing the very idea of 
> columns?


Mini-glossary of computing


Definition
Term




Computer
An electronic device for information processing.



Driver
A computer program taking care of direct communication with a 
peripherial 
device.
A person who drives a vehicle.





Mini-glossary of computing


Definition
Term




Computer
An electronic device for information processing.


Driver
A computer program taking care of direct communication with a 
peripherial 
device.
A person who drives a vehicle.




Now, is it abusing of columns, I really don't know. If a column is a 
presentation definition, maybe. If it just a container for a key or a 
value, I don't think so. After all, CSS encompasses everything in 
boxes, including characters.
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] Definition list and tables: what's the difference ?

[David Latapie]

On Tue, 13 Feb 2007 22:23:53 -0500, Matthew Raymond wrote:
> This whole thread is as silly as saying that we
> should replace  with  because  can express the same
> structure. Structure is important, but it's only half of the equation.

So you recognize the thread it NOT silly ;-)

Let me explain: A paragraph is supposed to encompass an idea, while a 
div really is a block-level . The first has semantics, the second 
has none, so a  shall not be replace by a  -- contrary to a 
definition list, where the relationship is the same -- not even 
counting header, colgroup...

Accessorily, I believe there is a need for an equivalent of  for 
.  marks a term to define, but what is the marker for its 
definition?
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

Re: [whatwg] Authoring Re: several messages about HTML5

[Dave Raggett]

Thanks Charles for that really inciteful response. I very much agree 
with the need to get authoring tool support for semantically richer 
markup. Microformats are great - but how many people find that they 
can't be bothered with that level of detail, especially when using a 
wysiwyg style of editor? Rather than considering this to be somebody 
else's problem, it seems timely to try and do something about it 
myself. I am therefore devoting a lot of my time into developing a 
new kind of authoring environment that combines a semantic view with 
a wysiwyg view, and which will use dictionaries to generate the 
markup that few of us can be bothered to write directly.


What has this to do with HTML5, I hear you asking?  The answer is 
not about markup per se, but rather about the scripting interfaces 
that browsers provide, and which make possible writing such 
authoring tools as cross-browser web applications. It has taken a 
great deal of effort to coax IE into providing DOM2 ranges, as 
needed to support detecting the location of mouse clicks and to 
moving beyond "italic" and "bold" as the only kinds of emphasis that 
IE supports with execCommand and text ranges. Keyboard events are 
the other major source of pain. The good news is that editing 
support can be implemented in an interoperably way across all modern 
web browsers without the need for changes to HTML and without any 
dependence on designMode or contentEditable. Improvements to 
keystroke events would be valuable and I look forward to widespread 
support for DOM3 events.


This brings us back to what kind of innovation is needed for the 
creation of web content. One thought is to respect the separation of 
roles in teams, for instance, text content, graphics design, user 
interface design, data modelling and information flows. Authoring 
tools need to respect this separation of roles and avoid burdening 
people with tasks that are inappropriate to their roles. If you are 
a journalist providing copy, then you shouldn't be worried about 
layout and styling. You would also expect help with finding and 
linking to appropriate references and photos, although these might 
be added by someone else. It is quite unlikely that you would be 
interested in element class attribute values etc.


Paper still has lots of advantages for editorial work, and I rather 
like Malcom Gladwell's "The social life of paper"


  http://www.gladwell.com/2002/2002_03_25_a_paper.htm

We need to think more about how to enable the kinds of affordances 
that pen and paper provide for various tasks, and what kinds of web 
authoring tools this would permit.


 Dave Raggett <[EMAIL PROTECTED]> http://www.w3.org/People/Raggett

On Wed, 21 Feb 2007, Charles McCathieNevile wrote:


On Wed, 21 Feb 2007 03:40:09 +0100, Lachlan Hunt <[EMAIL PROTECTED]> wrote:


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.


(Summary: What Hixie said. But I show my reasoning ;) ).

Hmmm. It is more complex than that, but not much. It is very easy 
to use Word to create good clean structured content, which can be 
straightforwardly transformed to good clean semantic HTML (or PDF 
for that matter). And likewise, it isn't that hard with other 
tools. The thinking outside the box a bit has been a solved 
problem since before Word was a WYSIWYG tool. Deployment, and 
getting the right features used, is a different story.


The trick is in the workflow, or ecosystem, or whatever you call 
it. People started out in the 80s learning to press the BOLD 
button, or the larger font button, to make headings. This was easy 
- it matched what they had done with a typewriter or more commonly 
with a pen at school, and the set of semantics available matched 
the small number of possibilities (CAPS, underlining, bold or 
italic with a fancy golfball typewriter. As people got printers 
and desktop publishing a few people made the crazy multi-font 
unreadable pages that were all the rage in the mid-80s (just as 
multi-coloured headings like the google logo were all the rage in 
the mid-90s - but seem to have all but vanished now 

[whatwg] X/HTML5 and DocBook

[David Latapie]

Hello,

I never used it, but a common complaint about DocBook is that there is 
too much tags.

Now, considering how microformats seems to be the Next Big Thing™ (and 
we are talking quite a lot on this ML about this technology), could 
someone with a background in DocBook tell me (us) how 
X/HTML5+microformats differs from DocBook?

Please remember I may have wrong ideas about DocBook (or about X/HTML5, 
for that matter).

Thank you
-- 
 U+0F00
http://blog.empyree.org/en (English)
http://blog.empyree.org/fr (Français)
http://blog.empyree.org/sl (Slovensko)

[whatwg] Private class names (was "several messages about HTML5")

[Michel Fortin]

Le 2007-02-21 à 4:41, Gervase Markham a écrit :

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.


You're proposing something that looks like the path of less  
resistance for adoption of the spec. While this is certainly worth  
something, it also happen to be the path of less intensive to use the  
predefined class names, or to register new ones when you need one,  
since private-domain class names would be prettier and easier to type  
than the standardised ones. Beside, it would also make it impossible  
to register class names currently in use by microformats.


Because of all that, I think it makes more sense that the private  
domain be the one that starts with a dash. There is also the benefit  
that you can create a similar private domain for link types (for the  
rel attribute).


By the way I know the current predefined class model is lacking in  
certain areas, most notably it makes clashes inevitable (although how  
much this is a problem is still open for debate). It could certainly  
be scrapped altogether in the future, but in the meanwhile I want to  
improve it little by little. Maybe with enough incremental  
improvements like this one it'll become good enough for a majority of  
people.



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

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] Input field's hint value

[Alexey Feldgendler]

On Wed, 21 Feb 2007 11:28:47 +0100, Wolfram Kriesing <[EMAIL PROTECTED]> 
wrote:

> I was searching, but didnt find a hint-attribute for an input. The
> more often we are using inline editing, the more the need for the
> following is rising, imho:
>
> 
>
> The text "Enter your title here" is shown as the value while no value
> is given, or when the field is empty, upon focusing the element this
> string disappears. If no value was entered this text is shown again
> ... I guess its clear what I think of here, a lot of apps already have
> that.
> I could also imagine styling this hint text differently, may be customizable.
> Is there already such a thing?

>From the semantic standpoint, I believe this is what the title attribute 
expresses.

Please somebody correct me if I'm wrong, but this behavior (show the value of 
the title attribute whenever the control is not focused and has empty value) 
can 
already be specified with CSS over WF2. 


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

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

[whatwg] Input field's hint value

[Wolfram Kriesing]

I was searching, but didnt find a hint-attribute for an input. The
more often we are using inline editing, the more the need for the
following is rising, imho:

  

The text "Enter your title here" is shown as the value while no value
is given, or when the field is empty, upon focusing the element this
string disappears. If no value was entered this text is shown again
... I guess its clear what I think of here, a lot of apps already have
that.
I could also imagine styling this hint text differently, may be customizable.
Is there already such a thing?

--
cu

Wolfram

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

[whatwg] Authoring Re: several messages about HTML5

[Charles McCathieNevile]

On Wed, 21 Feb 2007 03:40:09 +0100, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

> 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.

(Summary: What Hixie said. But I show my reasoning ;) ).

Hmmm. It is more complex than that, but not much. It is very easy to use Word 
to create good clean structured content, which can be straightforwardly 
transformed to good clean semantic HTML (or PDF for that matter). And likewise, 
it isn't that hard with other tools. The thinking outside the box a bit has 
been a solved problem since before Word was a WYSIWYG tool. Deployment, and 
getting the right features used, is a different story.

The trick is in the workflow, or ecosystem, or whatever you call it. People 
started out in the 80s learning to press the BOLD button, or the larger font 
button, to make headings. This was easy - it matched what they had done with a 
typewriter or more commonly with a pen at school, and the set of semantics 
available matched the small number of possibilities (CAPS, underlining, bold or 
italic with a fancy golfball typewriter. As people got printers and desktop 
publishing a few people made the crazy multi-font unreadable pages that were 
all the rage in the mid-80s (just as multi-coloured headings like the google 
logo were all the rage in the mid-90s - but seem to have all but vanished now 
except for that example). Those quickly died out in the serious world, where 
people used the increased variety in typesetting to create documents that were 
visually very semantically clear. Even today, calls for academic papers will 
require very strict formatting for photo-ready copy, and there must be millions 
of documents adhering to the most popular of these formats.

What is lacking, all down the line, is the idea of understanding that the Web 
is not just a simple visual representation. Most people still don't think of 
looking at the Web on their phone as "real" (at least in the small group of 
western countries that dominate development of Web standards). Nor do most 
people know a lot about accessibility. Most people comissioning content want it 
to look good on their machine, and assume it looks good to everyone else too 
(after all, how many people are prepared to admit they have horrible design 
sense and make things that most people find ugly?).

Which reinforces the initial patterns we have for learning how to use tools. In 
most places children still learn to write with a pencil, which shapes their 
idea of conveying semantics. Then they are taught to use a keyboard, and convey 
semantics by people who learned it a long time ago, when visually was the only 
meaningful way. And then they get tools for creating the Web. Surprise 
surprise, in general the people who produce content (and are experts in content 
and couldn't care less about the underlying structure of the Web) keep doing 
what they have always done, and look for tools that are easy to use.

We are trying to change the way the world thinks about semantics. Little by 
little, it happens. Little by little people are realising that accessibility, 
or being friendly to mobile devices, or being able to repurpose the things they 
write, or something else, means that noting the underlying semantics is 
valuable. In a century we have made a little progress in changing things. 
People use underlining much less than they used to as a highlight, since they 
have learned that it means a link.

This change of approach to expression takes a long time to filter through to 
the world. One of the crucial things is working very hard on authoring tools, 
since only a tiny minority really writes code by hand. The tools themselves are 
often hand-crafted to produce code, but even that is not a given (and IMHO 
regarding that as a valid constraint is missing the most important point of the 
last decade of markup language history). The changes will come (and are coming, 
bit by bit). But looking for a rapid sea-change is somewhat naive. The old ways 
will last for decades, come what may. If we spend too much time w

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