date:20070103

On Thu, 4 Jan 2007, Anne van Kesteren wrote:
> On Thu, 04 Jan 2007 02:27:33 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > On Thu, 4 Jan 2007, Anne van Kesteren wrote:
> > > On Thu, 04 Jan 2007 02:14:37 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > > > How doesn't it introduce a condition? It's one big "if". In fact, it's
> > > > two of them.
> > > 
> > > To me it's ambiguous whether this "big 'if'" also applies to the
> > > "innerHTML case" or not.
> > 
> > Why is it ambiguous? The first if doesn't even mention innerHTML. I don't
> > really understand why it wouldn't apply.
> 
> So why mention "Otherwise" in that case? Say the stack is ("html", "y") 
> and we're in innerHTML mode. The second node in the stack is not "body" 
> so it's a parse error per the first paragraph. And then other parse 
> error per the second paragraph. It seems to me you only want a single 
> parse error.

Yes, we only want a single parse error. That's exactly it.

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

Re: [whatwg] and

James Graham wrote:
> FWIW, I know, offhand, the ISBN of exactly zero books (whereas I could 
> probably quote from several). Therefore it would take considerable 
> effort for me to find the ISBN of a book I was quoting (I would have to 
> spend time looking it up on the book or online somewhere), then more 
> effort to carefully copy the human unfriendly string into whatever tool 
> was demanding this apparently superfluous information. I would imagine 
> that "three seconds" is an underestimate of about an order of magnitude.

And then Julian Reschke chipped in by suggesting that "Amazon will tell
you" so that "30 seconds sounds more reasonable"!

What are you guys talking about? You've got this exactly backwards: you
don't consult online services to find out ISBNs (although you can); you
use ISBNs to find books on online services.

Let's try a little experiment. I have here a stopwatch. I go over to my
bookcase, close my eyes, stick out my hand and take the first book I
touch from the shelf. I place it beside my keyboard. I start my
stopwatch...

0-520-24073-1

Time taken: 7 seconds. How did I accomplish this astonishing feat? 

Since ISBN became an international standard in 1970, most books
published for mass distribution in developing countries have been
assigned an ISBN and marked with it. Typically, you'll find it either on
the back cover with the barcode or on the front leaves with the other
publication information, or (most usually) in both places, helpfully
labelled as "ISBN" and hyphenated. Wikipedia has a handy illustration:

http://en.wikipedia.org/wiki/International_Standard_Book_Number

In other words, for most books published in the last 37 years it's easy.
And if it isn't easy, then the book probably doesn't have an ISBN
anyway.

You can enter ISBNs straight into the search box at Amazon.com, if you
like. Try it with 0-520-24073-1.

As another experiment, I'm just going to type the plain text citation:

Joan Roughgarden, Evolution’s Rainbow: Diversity, Gender, and Sexuality
in Nature and People (Berkeley and Los Angeles, 2004).

Time taken: 36 seconds. No markup, no styling. Now let's try something
like what hCite may turn out to be:

http://microformats.org/wiki/citation

I'll mark up author, title, place of publication and date.

Joan Roughgarden,Evolution’s
Rainbow: Diversity, Gender, and Sexuality in Nature and People
(Berkeley and Los Angeles, 2004).

Time taken: 1 minute, 59 seconds. And yes, if you've eagle eyes you'll
have noticed I still managed to:

1) mistype vcard;

2) mess up the end  tag for ;

3) forget to add an end  for ;

4) miss out the space between the author and the title.

So that will be non-conformant, unparsable, and typographically
illiterate. Three cheers for the wonders of hand-coding. ;)

And if typing 10-13 digit numbers still sounds like too much hard work,
the state of the art is to dangle a book in front of your webcam and
have your software grab its details of the web's bibliographic
databases.

ISBNs may be all very well for modern books, I here the sceptics among
you cry, but what about all the other stuff on your shelves, from before
1970? Let's conduct another experiment. I return to my bookshelf and
pull out the mustiest, most obscure book I can find. I open it up
gingerly; it's trying hard to fall to bits. ISBN? Hah, this relic of
ancient days doesn't even have a publication date. But it has an author
and title, and that's all I need. I bang "emerson gem" into the search
form at http://worldcat.org/ , and I get back 6 choices.

http://worldcat.org/search?qt=worldcat_org&q=gem+emerson&submit=Search

I identify the right volume by looking at the publisher's name: "Lacey".
And here it is:

http://worldcat.org/oclc/36004436

The source includes an embedded OpenURL Context Object (look for the
span with class Z3988).

I suggest you guys confirm these highly scientific results with
experiments on your own bookshelves. ;)

James Graham reports from the front that: 
> I've never met anyone who enjoys filling in BibTeX citations, for
> example and that is of comparable difficulty to the process you
> advocate

The difficulty of filling in BibTeX citations rather depends on whether
you do it by laboriously by hand or whether you use software that will
query library databases for you and autofill most of the data.

As for people enjoying filling in citations, I've already pointed to two
communities crazy enough to /pay/ for the privilege of doing so: the
customers of LibraryThing and Delicious Library:

http://www.librarything.com/

http://www.delicious-monster.com/

Some of you seem to worry I propose forcing people dig up information in
which they have no interest. On the contrary, I see people cataloguing
tedious metadata, or struggling to find where quotations came from, and
want software to do it for them.

--
Benjamin Hawkes-Lewis

Re: [whatwg] EOF handling in the main phase


On Thu, 04 Jan 2007 02:27:33 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Thu, 4 Jan 2007, Anne van Kesteren wrote:

On Thu, 04 Jan 2007 02:14:37 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
How doesn't it introduce a condition? It's one big "if". In fact, it's  
two of them.


To me it's ambiguous whether this "big 'if'" also applies to the
"innerHTML case" or not.


Why is it ambiguous? The first if doesn't even mention innerHTML. I don't
really understand why it wouldn't apply.


So why mention "Otherwise" in that case? Say the stack is ("html", "y")  
and we're in innerHTML mode. The second node in the stack is not "body" so  
it's a parse error per the first paragraph. And then other parse error per  
the second paragraph. It seems to me you only want a single parse error.



--
Anne van Kesteren

Re: [whatwg] EOF handling in the main phase

On Thu, 4 Jan 2007, Anne van Kesteren wrote:
> On Thu, 04 Jan 2007 02:14:37 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > How doesn't it introduce a condition? It's one big "if". In fact, it's two
> > of them.
> 
> To me it's ambiguous whether this "big 'if'" also applies to the 
> "innerHTML case" or not.

Why is it ambiguous? The first if doesn't even mention innerHTML. I don't 
really understand why it wouldn't apply.

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

Re: [whatwg] as a wrapper for inline content

On Thu, 4 Jan 2007, Kornel Lesinski wrote:
> On Thu, 04 Jan 2007 00:58:34 -, Ian Hickson <[EMAIL PROTECTED]> wrote:
> 
> > What's the use case for  elements containing inlines?
> 
> From microformats.org:
> 
> 
>  http://tantek.com/";>Tantek Çelik
>  Technorati
> 

If that's an address:

   
http://tantex.com/";>Tantek Çelik 
Technorati
   

But yeah, I see what you're saying...

Hmm. I guess we could say it is block-or-structured-inline-but-not-both, 
like most of the other elements. That still prevents things like:

   
 ...
  ... 
   

...and:

   
 ...
 ...
   

...which are what I'm trying to avoid here.


> It can be generalized to "when  is used in place of elements with 
> inline content model and which are not in HTML." The simplest example 
> could be .

 handles that case.

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

Re: [whatwg] EOF handling in the main phase


On Thu, 04 Jan 2007 02:14:37 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
How doesn't it introduce a condition? It's one big "if". In fact, it's  
two of them.


To me it's ambiguous whether this "big 'if'" also applies to the  
"innerHTML case" or not.



--
Anne van Kesteren

Re: [whatwg] as a wrapper for inline content

2007-01-03 Thread Kornel Lesinski


On Thu, 04 Jan 2007 00:58:34 -, Ian Hickson <[EMAIL PROTECTED]> wrote:


What's the use case for  elements containing inlines?


From microformats.org:


 http://tantek.com/";>Tantek Çelik
 Technorati



It can be generalized to "when  is used in place of elements with  
inline content model and which are not in HTML." The simplest example  
could be .


--
regards, Kornel Lesiński

Re: [whatwg] EOF handling in the main phase

On Thu, 4 Jan 2007, Anne van Kesteren wrote:
> > 
> > Fixed. I think.
> 
> The "Otherwise" doesn't make much sense since the previous paragraph 
> didn't introduce a condition.

How doesn't it introduce a condition? It's one big "if". In fact, it's two 
of them.


> How about:
> 
> If the parser was originally created in order to
> handle the setting of an element's  title="dom-innerHTML-HTML">innerHTML attribute, and there's
> more than one element in the stack of open elements,
> and the second node on the stack of open elements is
> not a body node, then this is a parse
> error. (innerHTML case)
> 
> Otherwise, if there are more than two nodes on the stack
> of open elements, or if there are two nodes but the second
> node is not a body node, this is a parse
> error.

Isn't this just reversing the two paragraphs and moving the Otherwise to 
the other paragraph? What's the practical difference? I'm confused.

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

Re: [whatwg] as a wrapper for inline content


On Thu, 04 Jan 2007 01:58:34 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

It depends if by "early adopters" you mean people who just change the
DOCTYPE, or people who actually switch to using the new elements. We have
to balance making life easier for early adopters with making life better
on the long run.

What's the use case for  elements containing inlines?


It seems to be mostly used for constructs HTML5 solves by having a native  
element for it, like:


  01-01-2007

  

  ...

Early adopters, however, can't really use the new elements due to crazy  
parsing.



--
Anne van Kesteren

Re: [whatwg] Presentational safety valves

On Thu, 4 Jan 2007, Anne van Kesteren wrote:
> On Thu, 04 Jan 2007 01:50:34 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > >
> > > There are of course far more elements not in HTML5 than just . 
> > > It's not really clear to me what you mean here. Care to clarify?
> > 
> > I meant, elements that were absent from the HTML5 specs (WA1+WF2) but 
> > that I intend to add before final feature freeze.
> 
> Hmm, I was hoping that the ruby elements would be in there too. Oh, and 
> ! :-)

I don't personally know enough about  to spec it. I would certainly 
look at detailed  spec proposals (semantics, parsing, DOM) if they 
were comprehensive, and if they seemed sane, include them.

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

Re: [whatwg] EOF handling in the main phase


On Thu, 04 Jan 2007 01:49:17 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

I was wondering what "If there's more than one node on the stack of open
elements, or, if the parser was not originally created in order to
handle the setting of an element's innerHTML attribute (innerHTML case)
and the second node on the stack of open elements is not a body node,
this is a parse error." exactly means. I came up with two variations:
[...]


Fixed. I think.


The "Otherwise" doesn't make much sense since the previous paragraph  
didn't introduce a condition. How about:


If the parser was originally created in order to
handle the setting of an element's innerHTML attribute, and there's
more than one element in the stack of open elements,
and the second node on the stack of open elements is
not a body node, then this is a parse
error. (innerHTML case)

Otherwise, if there are more than two nodes on the stack
of open elements, or if there are two nodes but the second
node is not a body node, this is a parse
error.


--
Anne van Kesteren

Re: [whatwg] Presentational safety valves


On Thu, 04 Jan 2007 01:50:34 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

There are of course far more elements not in HTML5 than just .
It's not really clear to me what you mean here. Care to clarify?


I meant, elements that were absent from the HTML5 specs (WA1+WF2) but  
that I intend to add before final feature freeze.


Hmm, I was hoping that the ruby elements would be in there too. Oh, and  
! :-)



--
Anne van Kesteren

Re: [whatwg] as a wrapper for inline content

On Sat, 30 Dec 2006, Henri Sivonen wrote:
>
> I suspect requiring the content model of  to be block only might be 
> an annoyance as far as a smooth upgrade path goes. Extremely superficial 
> anecdotal evidence suggests that even making the content model bimorphic 
> makes some Strict blogs not conform to an (X)HTML5 draft grammar.

Indeed.


> It seems to me that  is often used as an adapter that allows 
> DTD-valid Strict pages to put inline stuff where the DTD wants block.

Yes, it is used as a way to step around strictness requirements. It's a 
bug in HTML4 that people have been abusing, as far as I can tell.


> I can see why this might be unpleasant or inelegant, but do we really 
> want to annoy the potential early adopters who are now using such tricks 
> to make their pages valid as Strict? (The easy way to weasel out is, of 
> course, to state that a  that only has inline content constitutes a 
> paragraph. And, behold, paragraphs with struct-inline children become 
> possible in text/html as a side effect. :-)

It depends if by "early adopters" you mean people who just change the 
DOCTYPE, or people who actually switch to using the new elements. We have 
to balance making life easier for early adopters with making life better 
on the long run.

What's the use case for  elements containing inlines?

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

Re: [whatwg] Presentational safety valves

On Thu, 4 Jan 2007, Anne van Kesteren wrote:
>
> On Thu, 04 Jan 2007 00:57:46 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > For the record, note that  is now in HTML5. If I recall correctly,
> > the only element now missing is , and that will be added in due
> > course (when I get around to speccing what WYSIWYG editors are allowed to
> > do).
> 
> There are of course far more elements not in HTML5 than just . 
> It's not really clear to me what you mean here. Care to clarify?

I meant, elements that were absent from the HTML5 specs (WA1+WF2) but that 
I intend to add before final feature freeze.

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

Re: [whatwg] EOF handling in the main phase

On Mon, 1 Jan 2007, Anne van Kesteren wrote:
>
> I was wondering what "If there's more than one node on the stack of open 
> elements, or, if the parser was not originally created in order to 
> handle the setting of an element's innerHTML attribute (innerHTML case) 
> and the second node on the stack of open elements is not a body node, 
> this is a parse error." exactly means. I came up with two variations:
> [...]

Fixed. I think.


> After that it says "Stop parsing." but it isn't defined how the 
> remaining tokens are to be popped of from the stack of open elements. 
> Shouldn't that be covered?

Doesn't matter how they are popped from the stack. You could just throw 
the stack away and be done. Once you stop parsing, the stack is never 
again used, and never affects the document.

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

Re: [whatwg] scrolling


On Thu, 04 Jan 2007 01:00:53 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

[1] http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.src.html
[2] http://xulplanet.com/ndeakin/xul/specs/scrollspec.html


I believe Anne is working on the spec ([1]) to cover these. Anne?


Yes, that's the plan. I think www-style is the most appropriate place for  
feedback (given that it concerns rendering and the work is "hosted" by the  
CSS WG), but I don't really care where it comes from, as long as I see it!  
:-)




If he's not, then yeah, I'll have to make sure they're specced in WA1. I
recommend coordinating with Anne.



--
Anne van Kesteren

Re: [whatwg] Presentational safety valves


On Thu, 04 Jan 2007 00:57:46 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:

For the record, note that  is now in HTML5. If I recall correctly,
the only element now missing is , and that will be added in due
course (when I get around to speccing what WYSIWYG editors are allowed to
do).


There are of course far more elements not in HTML5 than just . It's  
not really clear to me what you mean here. Care to clarify?



--
Anne van Kesteren

Re: [whatwg] scrolling

On Thu, 28 Dec 2006, Neil Deakin wrote:
>
> Right now there isn't any specification for retrieving or modifying the 
> scroll position of a scrollable area. There's a brief mention of the 
> scroll* properties as part of the CSS object model draft [1] but I'm not 
> sure if the css wg is the right place for that work, or whether this 
> would better be part of the Web Applications spec either current or 
> future. Regardless, I've written a proposal at [2] for how the scroll* 
> properties could work as well as notes about how existing browsers 
> handle them. Thoughts?
> 
> [1] http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.src.html 
> [2] http://xulplanet.com/ndeakin/xul/specs/scrollspec.html

I believe Anne is working on the spec ([1]) to cover these. Anne?

If he's not, then yeah, I'll have to make sure they're specced in WA1. I 
recommend coordinating with Anne.

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

Re: [whatwg] Presentational safety valves

On Wed, 3 Jan 2007, Matthew Paul Thomas wrote:
> 
> As another analogy, in a recent message to Ian I referred to such 
> presentational elements as "safety valves".
> 
> Whenever someone uses , don't say "alas, that's a hole in HTML"; 
> say "hooray, that's someone who isn't misusing ".

For the record, note that  is now in HTML5. If I recall correctly, 
the only element now missing is , and that will be added in due 
course (when I get around to speccing what WYSIWYG editors are allowed to 
do).

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

Re: [whatwg] several messages

On Tue, 26 Dec 2006, Mike Schinkel wrote:
> 
> I'm wondering if you collectively would consider adding the following to 
> the spec; a recommendation that clients offer two "modes"; one mode 
> being for users where the spec works as currently envisioned. The second 
> mode would be for web developers and would generate errors for invalid 
> markup as opposed to generating no errors (Ian had said it was preferred 
> to not generate errors for invalid markup to ensure users were willing 
> to use browsers based on the newer spec; a dual mode would give the best 
> of both worlds.)
> 
> If all clients had such a dual mode, I think it would be much more 
> likely that web developers would create valid markup.  I just hope you 
> guys can envision that being something mentioned and marked as "SHOULD" 
> in the spec.

The spec already allows this:

# This specification defines the parsing rules for HTML documents, whether 
# they are syntactically valid or not. Certain points in the parsing 
# algorithm are said to be parse errors. The error handling for parse 
# errors is well-defined: user agents must either act as described below 
# when encountering such problems, or must abort processing at the first 
# error that they encounter for which they do not wish to apply the rules 
# described below.

The "wishes" of the user agent described above could easily change at the 
whim of the user, via a user interface control such as you propose.

On Sat, 30 Dec 2006, Mike Schinkel wrote:
> 
> It appears that many of my suggestions are considered to be several 
> longer term participants to be "out of scope."  Unfortunately I have 
> been unable to indentify any guidance in my readings of the 
> specification guidelines[1] that would indicate why my suggestions would 
> be considered out of scope. It would be very helpful for me as well as 
> everyone else to avoid wasting time if you could point me to findings 
> and/or alternate authoritative documents, or even specific wording in 
> [1] that would allow me to determine in advance which things that I 
> might consider proposing would be out of scope.  And specifically it 
> would be helpful if you could point me to such guidance that would 
> indicate why this latest proposal is out of scope. Thanks in advance.

Basically, anything that user agents must do the same in order for content 
to be treated equivalently is in scope. User interface is out of scope (it 
doesn't matter if the browser has an address bar or not, it's still 
processing the Web the same way, for example). Performance characteristics 
are out of scope (it doesn't matter how fast something happens: a browser 
that renders a page in a minute and one that renders it in a second are 
both equivalent). Implementation internals are out of scope (it doesn't 
matter if the browser implements the spec using a neural network or 
imperative algorithms, so long as the end result is the same).

On Sat, 30 Dec 2006, Mike Schinkel wrote:
> > 
> > "This specification is limited to providing a semantic-level markup 
> > language and associated semantic-level scripting APIs for authoring 
> > accessible pages on the Web ranging from static documents to dynamic 
> > applications." 
> > http://www.whatwg.org/specs/web-apps/current-work/#scope
> 
> That said, I'd like to question if the scope is actually sufficient?  
> If one of the realities of the HTML5 spec is dealing with tag soup, I 
> would think that a scope that does not attempt to address that issue is 
> A Bad Thing(tm).

The "tag soup" is just the parsing rules. The parsing rules are part of 
the markup language. The markup language is explicitly in scope.

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

Re: [whatwg] and

2007-01-03 Thread Karl Dubost



Le 4 janv. 2007 à 01:41, Henri Sivonen a écrit :

On Jan 3, 2007, at 18:22, Karl Dubost wrote:

As a side note, the fact that human authors are the main users of  
the data doesn't mean that the rest of tools is useless.


If HTML had unambiguous sourcing of quotations, what cool software  
would you write that would consume the markup?


Given into account that the notion of "cool" is very subjective and  
tied to one's interests.


* http://web.archive.org/web/20030211001151/http://diveintomark.org/ 
archives/quotations/
http://web.archive.org/web/20030207035922/diveintomark.org/archives/ 
citations/

http://diveintomark.org/archives/2003/01/28/autocontent
* technorati, bloglines like
http://www.bookorati.com/
* threading for commenting system on Weblogs
a database of well known quotations, authors.
a databse of poetry
frequency analysis of quotes for texts.

I can also imagine a tool which displays possibility to have more  
information on the quotes contained in the page by displaying a  
widget with more exploration: spontaneous buy of the source which has  
been cited (without to necessary use amazon), or get more information  
about an author, redirecting to wikipedia

ala PageMapper http://labs.metacarta.com/PageMapper/
or OpenLayers http://openlayers.org/



How would you convince authors to produce the markup?


For those who have an immediate benefits for their own markup do the  
effort. It is a bit like math. Most people use substraction and  
addition, a bit less multiplication, a bit less division, though on  
simple calculator, there are the 4 operations.


For weblogs authoring tools, definitely in some circumstances, the  
forms or templating of any kind.


http://www.w3.org/2000/08/eb58

See for example, a simple way with a bookmarklet to cite a Web document.
javascript:void(window.open('%20').document.write('%3Ctextarea% 
20rows=20%20cols=80%3E%3Cblockquote%20cite=%22'+location.href+'%22%3E 
\n\n%3Cp%3E'+document.getSelection()+'%3C/p%3E\n\n%3C/blockquote%3E\n 
\n%3Cp%3E%3Ccite%3E%3Ca%20href=%22'+location.href+'%22% 
3E'+document.title+'%3C/a%3E%3Cbr%20/%3E'+new%20Date 
(document.lastModified).toUTCString()+'%3C/cite%3E%3C/p%3E%3C/textarea 
%3E'))


In NetNewsWire, it already exists, you can Copy a quote, the  
generated markup is not "perfect"  but it shows exactly one of the  
possibility for authoring it.
http://jumpserve.com/blanco/archives/2002/08/30/cool-netnewswire- 
blogging-feature/

http://face.centosprime.com/macosxw/?p=98

In fact the feature of "copy HTML with attribution" could be in any  
kind of Web browsers by default.





--
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] and

2007-01-03 Thread Julian Reschke


James Graham schrieb:
FWIW, I know, offhand, the ISBN of exactly zero books (whereas I could 
probably quote from several). Therefore it would take considerable 
effort for me to find the ISBN of a book I was quoting (I would have to 
spend time looking it up on the book or online somewhere), then more 


Amazon will tell you.

effort to carefully copy the human unfriendly string into whatever tool 
was demanding this apparently superfluous information. I would imagine 
that "three seconds" is an underestimate of about an order of magnitude.


30 seconds sounds more reasonable.

This last bit is the killer; people hate doing mundane things even when 
they have to (I've never met anyone who enjoys filling in BibTeX 
citations, for example and that is of comparable difficulty to the 
process you advocate), and certainly won't do if if they see no benefit 
for their efforts (even if some minority group will).


Best regards, Julian

Re: [whatwg] and

2007-01-03 Thread James Graham


Benjamin Hawkes-Lewis wrote:

Henri Sivonen wrote:


 And I am unconvinced that authors would be willing to spoon feed data mining  
tools, considering that the beneficiaries of such spoon feeding are  
not the authors themselves nor even their direct human audience.


So you want to quote a book. Do you choose to:

a) Spend a minute gathering the relevant information and arranging it
into a marked up and styled citation?

b) Spend three seconds typing an ISBN into a box and get the same
result?

I choose b).


FWIW, I know, offhand, the ISBN of exactly zero books (whereas I could 
probably quote from several). Therefore it would take considerable 
effort for me to find the ISBN of a book I was quoting (I would have to 
spend time looking it up on the book or online somewhere), then more 
effort to carefully copy the human unfriendly string into whatever tool 
was demanding this apparently superfluous information. I would imagine 
that "three seconds" is an underestimate of about an order of magnitude.


This last bit is the killer; people hate doing mundane things even when 
they have to (I've never met anyone who enjoys filling in BibTeX 
citations, for example and that is of comparable difficulty to the 
process you advocate), and certainly won't do if if they see no benefit 
for their efforts (even if some minority group will).


--
"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] and

Anne van Kesteren wrote:
> Well, the reason I started this thread was to provide a replacement /  
> alternative to the cite="" attribute as defined for the  and  
>  elements using some terminology the HTML5 proposal already provided.  
> Mostly to make the metadata more "visual".

An unambiguous association between q/blockquote and a cite URI is the
key thing. The spec as it stands currently lacks this for q without the
cite attribute.

I'm not constitutionally opposed to making the metadata "more visual" in
itself, although I think it would be more user-friendly, efficient, and
flexible to require UAs to expose the metadata than to require authors
to produce a rendering themselves. It would also be a bit of a break
with tradition, but one I think would ultimately be for the best.

So long as we have an unambiguous association, we could at least write
tools to regenerate citation text in a different citation style
automatically. Of course, then one might begin to wonder why authors
were being required to write out, mark up, and style citation text in
the first place ...

I do think authors still need to be able to specify their own citation
metadata when required, largely because of failings in HTML's document
structure which mean that with many documents you can get a fragment
identifier but can't work out what that fragment actually represents:
it's just another div. (Although an id like "comment-345" does give one
a clue.) Fortunately, HTML5 will make that situation a bit better thanks
to the  element.

Of course one could bring custom metadata of this sort within the URI
model easily enough, by using a TinyURL-type lookup service that
included the metadata in the URI.

--
Benjamin Hawkes-Lewis

Re: [whatwg] and

Henri Sivonen wrote:

> Assuming that putting an ISBN URI in attribute somewhere solves  
> anything on its own is an illusion. If the source is hidden metadata,  
> it is mostly useless, because the reader doesn't read it. If the UA  
> is expected to render the information about the source somehow, the  
> problem of presenting sources is just moved to a different place.

In other words, if UAs are forced to display citation information, then
authors no longer have to worry about it. Sounds good to me.

> I'll be more convinced about "tools will save us" once I first see  
> that working on a smaller scale than the Web. Let's say TeXlipse with  
> the described UI generating BibTeX entries and inserting the proper  
> \cite{} on the LaTeX side.

I'm baffled by this. I don't know enough about Tex or TeXlipse to
understand why you think this would be a helpful test of the interface.
I'm not even sure how it would apply to the Tex world. As far as I can
see, it's like asking for an implementation of anchor links in TeXlipse.
Might you elaborate on why this would be a better proof of concept than
a Firefox extension?

> How much data is provided depends on the type of writing. If someone  
> quotes someone else's blog, quotation marks and a plain  back are enough. 

Well, perhaps. But an interface like I am describing would be less
complicated than the current process of copying text, putting it in
quotation marks, copying a link, putting it in an  element, writing
some link text, and then correcting the link so that ampersands are
correctly encoded.

> If you want to designate the source, you need to know it and express  
> it in a human-readable way. I am not suggesting any particular  
> formatting. 

But authors /do/ have to use particular formattings: those typographic
conventions you mentioned earlier.

> Not having to bear the cost of producing semantic quotation markup.
> Metadata and semantic markup are *not* without a cost.

You need to factor the real costs of linking to web content and of
concocting print-style citations with markup and CSS into your equation.
The "metadata" is the same in either case.

> Out of the feature range that UA implementors might want to implement

Why mightn't UAs want to implement it?

> “Quotation” (Source)
> 
> Punctuation and plain links go a long way for human readers.

There is no way for machines to conclusively differentiate quotation
punctuation from non-quotation punctuation. If a human listener (e.g. a
screen reader user) wishes to sure that she is not missing quotations,
she must listen to all the punctuation. Even then, it may be somewhat
unclear. But listeners do not want to listen to all the punctuation,
because the majority of it is superfluous.

Using punctuation instead of markup also makes it harder to go back and
find the quotation text in the source, or to verify that quotations are
accurate.

With plain links, all the metadata has to be structured and formatted a
s link text.

In any case, there is nothing preventing UAs rendering q and cite in
that fashion.

>  And I am unconvinced that authors would be willing to spoon feed data mining 
>  
> tools, considering that the beneficiaries of such spoon feeding are  
> not the authors themselves nor even their direct human audience.

So you want to quote a book. Do you choose to:

a) Spend a minute gathering the relevant information and arranging it
into a marked up and styled citation?

b) Spend three seconds typing an ISBN into a box and get the same
result?

I choose b).

(As an aside, people seem quite happy to spoon feed data mining tools.
They'll even pay for the privilege. Look at LibraryThing and Delicious
Library!)

--
Benjamin Hawkes-Lewis

Re: [whatwg] and


On Wed, 03 Jan 2007 18:34:08 +0100, Henri Sivonen <[EMAIL PROTECTED]> wrote:
This may look snarky, but it seems to me that this thread is mainly  
about finding a problem that , cite='' and  would solve and  
then tightening their definitions so that they could actually solve that  
problem.


Well, the reason I started this thread was to provide a replacement /  
alternative to the cite="" attribute as defined for the  and  
 elements using some terminology the HTML5 proposal already provided.  
Mostly to make the metadata more "visual".



--
Anne van Kesteren

Re: [whatwg] and


On Jan 3, 2007, at 19:05, Sander Tekelenburg wrote:


At 22:26 -0500 UTC, on 2007-01-02, Matthew Raymond wrote:

[...]


   Okay, how 'bout this:

| 
|   
| rhubarb rhubarb rhubarb
| [Nemo, Works, IV]
|   
| 


FWIW, I still cannot follow exactly what problem people are trying  
to solve

in this thread.


This may look snarky, but it seems to me that this thread is mainly  
about finding a problem that , cite='' and  would solve and  
then tightening their definitions so that they could actually solve  
that problem.


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

Re: [whatwg] and

2007-01-03 Thread Sander Tekelenburg

At 22:26 -0500 UTC, on 2007-01-02, Matthew Raymond wrote:

[...]

>Okay, how 'bout this:
>
> | 
> |   
> | rhubarb rhubarb rhubarb
> | [Nemo, Works, IV]
> |   
> | 

FWIW, I still cannot follow exactly what problem people are trying to solve
in this thread.


-- 
Sander Tekelenburg
The Web Repair Initiative:

Re: [whatwg] and

2007-01-03 Thread Rimantas Liubertas


So in HTML6.1 we are left with span and a.
If you're going that far, why keep ?  is clear enough.
One element to rule them all, one element to...never mind.


Hmm... To paraphrase one saying: every markup language can be reduced
by one element, and in every markup language there is at least one
element with the wrong semantics.

So: every markup language can be reduced to one element with the wrong
semantics.


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

Re: [whatwg] and

2007-01-03 Thread David Walbert



On Jan 3, 2007, at 11:37 AM, Rimantas Liubertas wrote:


So in HTML6.1 we are left with span and a.


If you're going that far, why keep ?  is clear  
enough. One element to rule them all, one element to...never mind.


:-)

David


_
David Walbert
LEARN NC, UNC-Chapel Hill
[EMAIL PROTECTED]

Re: [whatwg] and


On Jan 3, 2007, at 18:22, Karl Dubost wrote:

As a side note, the fact that human authors are the main users of  
the data doesn't mean that the rest of tools is useless.


If HTML had unambiguous sourcing of quotations, what cool software  
would you write that would consume the markup?


How would you convince authors to produce the markup?

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

Re: [whatwg] and

2007-01-03 Thread Rimantas Liubertas


/me creates HTML 6.0

Just 4 elements
html, div, span, a
and a few attributes.
class, href, title, id, rel, etc

Human audience will be satisfied. A lot simpler to type. For the rest
it is just a question of css and appropriate class. I would like to
have role and about though, and I'm satisfied. Useless semantics
[Henri Sivonen (c)] defined by profiles with values of attributes.


Cannot html element be dropped safely? And one of the div-span pair should go.
I have mixed feelings here - div is shorter, but span looks more apropriate:
it can span a word, or it can span a paragraph...

So in HTML6.1 we are left with span and a. All the mess was moved to
class and rel
attributes  :)


And sincerely I do not think the addition of elements will solve many
things for HTML.


Agrred. But this is very very tough problem - where to draw the line.


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

Re: [whatwg] and

2007-01-03 Thread Karl Dubost



Le 4 janv. 2007 à 00:24, Henri Sivonen a écrit :

“Quotation” (Source)

Punctuation and plain links go a long way for human readers. And I  
am unconvinced that authors would be willing to spoon feed data  
mining tools, considering that the beneficiaries of such spoon  
feeding are not the authors themselves nor even their direct human  
audience.


/me creates HTML 6.0

Just 4 elements
html, div, span, a
and a few attributes.
class, href, title, id, rel, etc

Human audience will be satisfied. A lot simpler to type. For the rest  
it is just a question of css and appropriate class. I would like to  
have role and about though, and I'm satisfied. Useless semantics  
[Henri Sivonen (c)] defined by profiles with values of attributes.


As a side note, the fact that human authors are the main users of the  
data doesn't mean that the rest of tools is useless.


And sincerely I do not think the addition of elements will solve many  
things for HTML.



--
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] and

On Jan 3, 2007, at 16:28, Benjamin Hawkes-Lewis wrote:

Henri Sivonen wrote:

First, we should consider how people writing for traditional print
media would express quotations and sources.

I agree we should consider this, but why should we consider
this /first/?

Because it establishes the baseline that is compatible with the way
most people think of writing and upon which markup would be expected
to improve.

If improvements above that baseline turn out to be very expensive in
proportion to the benefit, we should just stick to the baseline.

(They'd use typographic conventions and words.)

It's print media. What else could they use?

Nothing. Yet, the quotation and source get communicated to human
readers.

Then we should consider if this is enough for
the Web or whether there could *realistically* be cases where
consuming software could serve users notably better for non-niche use
cases if there was more data available (i.e. big wins--not just
chasing diminishing returns).

Blogs, comment threads, forums, academic writing, books,
journalism, and

emails are not "niche use cases". In all of these cases, there is a
clear advantage to making it easy for authors to create accurate
quotations where the reader can easily get information about the
source

and jump to the source.

You can accomplish that in a way that authors understand by using the
conventions that you'd use on the print media plus making the piece
of text that names the source a usual HTML link (plain

If it turns out that having additional data would be a big win, we
should consider the cost and incentives
of providing that additional data and whether authors can
realistically provide the additional data (i.e. do they even know
it).

With print-style quotations, they need to know a lot of "additional
data" about the quoted work, and then they need to consult their
manual

of style to work out how on earth to cite it. With the sort of
machine-processable cited quotations I am advocating, they need to
know

far less about either the quoted work or style conventions.

Assuming that putting an ISBN URI in attribute somewhere solves
anything on its own is an illusion. If the source is hidden metadata,
it is mostly useless, because the reader doesn't read it. If the UA
is expected to render the information about the source somehow, the
problem of presenting sources is just moved to a different place.

For example,
found some text you want to quote in a web page? Select it, click
"Copy

as quotation". Go somewhere else, and click "Insert as quotation." Or,
for example, found some text you want to quote in a book? Go to the
insertion point, click "Insert quotation", fill in an ISBN (or author,
title, date, or select from a list of remembered works), fill in a
start

and end page, fill in the quotation text, and you're done.

I'll be more convinced about "tools will save us" once I first see
that working on a smaller scale than the Web. Let's say TeXlipse with
the described UI generating BibTeX entries and inserting the proper
\cite{} on the LaTeX side.

If this analysis suggests that authors would be able and
incentivized to provide the additional data, only then should we
design markup for it.

If they're citing materials at all, then they already are
providing /more/ additional data then my vision of how this should
work

would require.

How much data is provided depends on the type of writing. If someone
quotes someone else's blog, quotation marks and a plain back are enough. For an academic paper, a professor or a peer
reviewer is going to want more data, but still it isn't realistic to
assume that non-technical bloggers would be bothered to provide much
more than the link to the source.

Requiring ordinary end-users to do /any/ of the following
tasks by hand seems unrealistic:

Indeed.

Indeed, so why are you suggesting we require them to do task 4
(which is

one of the hardest)?

If you want to designate the source, you need to know it and express
it in a human-readable way. I am not suggesting any particular
formatting. Just doing something that readers will understand. Doing
anything less than that would amount to not designating the source.
(Obviously.)

Or, authors could simply not mark up the sources of quotations
unambiguously leaving it to readers to cope with the relationship of
quotations and sources the same way readers of papers publications
do.

What possible advantage would that provide?

Not having to bear the cost of producing semantic quotation markup.

Metadata and semantic markup are *not* without a cost.

If the spec is too "out there", it gets ignored.

Out where?

Out of the feature range that UA implementors might want to implement
or what normal people want to support on the authoring side.

Most notably, links are used on the Web to achieve a clear behavioral
goal in real software.

The behavioral goal is every bit as cl

Re: [whatwg] and

Henri Sivonen wrote:

> You seem to assume that there is a need to
>   1) Mark up quotations so that that software can unambiguously see  
> which DOM range was quoted.
>   2) Mark up sources of quotations in an unambiguous machine- 
> dereferencable way.
>   3) Associate the two unambiguously.

I don't see the distinction between 1, 2, and 3.

> First, we should consider how people writing for traditional print  
> media would express quotations and sources. 

I agree we should consider this, but why should we consider
this /first/?

> (They'd use typographic conventions and words.)

It's print media. What else could they use?

> Then we should consider if this is enough for  
> the Web or whether there could *realistically* be cases where  
> consuming software could serve users notably better for non-niche use  
> cases if there was more data available (i.e. big wins--not just  
> chasing diminishing returns).

Blogs, comment threads, forums, academic writing, books, journalism, and
emails are not "niche use cases". In all of these cases, there is a
clear advantage to making it easy for authors to create accurate
quotations where the reader can easily get information about the source
and jump to the source. (Well, except for authors attempting to use
quotations to mislead people. They'd begin to encounter certain
difficulties.)

> If it turns out that having additional data would be a big win, we
> should consider the cost and incentives  
> of providing that additional data and whether authors can  
> realistically provide the additional data (i.e. do they even know  
> it). 

With print-style quotations, they need to know a lot of "additional
data" about the quoted work, and then they need to consult their manual
of style to work out how on earth to cite it. With the sort of
machine-processable cited quotations I am advocating, they need to know
far less about either the quoted work or style conventions. For example,
found some text you want to quote in a web page? Select it, click "Copy
as quotation". Go somewhere else, and click "Insert as quotation." Or,
for example, found some text you want to quote in a book? Go to the
insertion point, click "Insert quotation", fill in an ISBN (or author,
title, date, or select from a list of remembered works), fill in a start
and end page, fill in the quotation text, and you're done.

> If this analysis suggests that authors would be able and  
> incentivized to provide the additional data, only then should we  
> design markup for it.

If they're citing materials at all, then they already are
providing /more/ additional data then my vision of how this should work
would require.

> > Requiring ordinary end-users to do /any/ of the following
> > tasks by hand seems unrealistic:
> 
> Indeed.

Indeed, so why are you suggesting we require them to do task 4 (which is
one of the hardest)?

> Or, authors could simply not mark up the sources of quotations  
> unambiguously leaving it to readers to cope with the relationship of  
> quotations and sources the same way readers of papers publications do.

What possible advantage would that provide? Sourcing quotations
unambiguously adds very little indeed to the challenges of writing
quotations and sources independently.

> If the spec is too "out there", it gets ignored.

Out where? Parsing metadata from hCite and META elements aren't exactly
challenging data-processing tasks. (Bandwidth /might/ be more of an
issue. But I suspect bandwidth problems could be circumvented entirely
using OpenURLs, if necessary, since with OpenURLs you can encode a lot
of information about the cited work into the URI.)

> Most notably, links are used on the Web to achieve a clear behavioral  
> goal in real software.

The behavioral goal is every bit as clear here: to make it easy to quote
stuff from somewhere else in such a way that people can:

a) get information about the quotation's source

b) go to the quotation's source

This couldn't be further from semantics for the sake of semantics. It's
as fundamental as .

--
Benjamin Hawkes-Lewis

Re: [whatwg] and


On Jan 3, 2007, at 13:03, Benjamin Hawkes-Lewis wrote:


Anne van Kesteren wrote:

Making quoting even more difficult is not better at all in my  
opinion.


Well, can you suggest an alternative way of associating different
instances of q, which may themselves contain citations from the quoted
material, with different instances of cite in the same paragraph?


You seem to assume that there is a need to
 1) Mark up quotations so that that software can unambiguously see  
which DOM range was quoted.
 2) Mark up sources of quotations in an unambiguous machine- 
dereferencable way.

 3) Associate the two unambiguously.

I very much doubt the need to mark up quoted DOM ranges unambiguously  
and to unambiguously give a machine-dereferencable source pointer. I  
also think that the issue is being approached from the wrong direction.


First, we should consider how people writing for traditional print  
media would express quotations and sources. (They'd use typographic  
conventions and words.) Then we should consider if this is enough for  
the Web or whether there could *realistically* be cases where  
consuming software could serve users notably better for non-niche use  
cases if there was more data available (i.e. big wins--not just  
chasing diminishing returns). If it turns out that having additional  
data would be a big win, we should consider the cost and incentives  
of providing that additional data and whether authors can  
realistically provide the additional data (i.e. do they even know  
it). If this analysis suggests that authors would be able and  
incentivized to provide the additional data, only then should we  
design markup for it.


Of course, this syntax is /only/ "difficult" if you type in your  
excerpt

manually.


"Tools will save us." Not likely.


Requiring ordinary end-users to do /any/ of the following
tasks by hand seems unrealistic:


Indeed.

If you do want to keep things really simple on the hand-coding end,  
the

cite attribute, not the cite element, is definitely the way to go


Or, authors could simply not mark up the sources of quotations  
unambiguously leaving it to readers to cope with the relationship of  
quotations and sources the same way readers of papers publications do.



Web Applications 1.0 could specifically require
browsers be able to retrieve, understand, and expose information from
OpenURL ContextObjects, Dublin Core, standard HTML META metadata, and
hCite. Styling might be rather vexing, however, although I suppose  
CSS3

could add relevant pseudo-classes if necessary?


If the spec is too "out there", it gets ignored.


I do recognize the cite attribute represents something of a break from
the conventions of print publishing, but then so does the href
attribute, and where would we be without that? :)


Most notably, links are used on the Web to achieve a clear behavioral  
goal in real software. The semantics of the link relationship are  
rarely expressed in practice.


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

Re: [whatwg] Semantic styling languages in the guise of HTML attributes.

Hallvord R M Steen wrote:
> Do you volunteer for the job of going through all "role" values
> and all current HTML element semantics and define which one takes
> presedence in each possible conflict? Matthew's point is that this
> task itself is massive.

Since both roles and microformats are open extension mechanisms, it's a
moving target and specifying rules of precedence would become harder and
harder, and impose a greater and greater burden of testing on extension
spec writers, as more and more roles and microformats are added.

One way to manage this complexity would be to group roles and
microformats into /types/ and set rules of precedence for those types.
Which could be done, but I don't see anyone doing it.

--
Benjamin Hawkes-Lewis

Re: [whatwg] and

Anne van Kesteren wrote:

> Making quoting even more difficult is not better at all in my opinion.

Well, can you suggest an alternative way of associating different
instances of q, which may themselves contain citations from the quoted
material, with different instances of cite in the same paragraph?

If you want to make it simpler, you could keep the spec's suggested
semantics for q and cite so long as there is only one cite in the
paragraph. This could complicate formatting however. How would one
differentiate in-text references using cite with cite elements that one
wished to display as footnotes?

Of course, this syntax is /only/ "difficult" if you type in your excerpt
manually. Requiring ordinary end-users to do /any/ of the following
tasks by hand seems unrealistic:

1) construct conformant HTML

2) construct conformant OpenURL context objects

3) construct conformant hCite microformatting

4) correctly arrange and style their citation according to a given set
of style rules

To require them to do all of these things would be hopeless; number 4
alone is challenging and stressful enough for university students. This
stuff all needs to be handled by a command along the lines of "Paste
excerpt". (If you're looking for an example implementation, hold on to
your hat. I'm developing one for Hypertextuality, but am currently still
working on the backend bibliographic querying.)

If you do want to keep things really simple on the hand-coding end, the
cite attribute, not the cite element, is definitely the way to go, since
bibliographic information can be encoded in the URI (have a look at
OpenURL) and metadata can be retrieved by requesting the page in the
case of web addresses. Web Applications 1.0 could specifically require
browsers be able to retrieve, understand, and expose information from
OpenURL ContextObjects, Dublin Core, standard HTML META metadata, and
hCite. Styling might be rather vexing, however, although I suppose CSS3
could add relevant pseudo-classes if necessary?

I do recognize the cite attribute represents something of a break from
the conventions of print publishing, but then so does the href
attribute, and where would we be without that? :)

One solution to associating cite elements with quotations might be to
keep the cite attribute, but add a scheme (or something) by which the
cite attribute could refer to a URI for citation data rather than the
work itself. Then it could refer to a cite element via a fragment
identifier. (The reason to have q refer to cite rather than the other
way round is that you never have two cites to one q, but you often have
more than one q to a cite.) 

--
Benjamin Hawkes-Lewis

Re: [whatwg] Semantic styling languages in the guise of HTML attributes.

2007-01-03 Thread Mike Schinkel

Hallvord R M Steen wrote:
> >  you have an opinion that few if any others are rallying behind.
> 
> Perhaps because it seems too obvious to discuss?

It doesn't seem obvious to anyone over on the microformat list, AFAICT.  If
it is that critical, why are all those to whom it is obvious making the case
on uf-discuss?

> You could go back to the list of markup samples, and tell us 
> for each of them what you feel the actual semantic of that 
> should be, and how it should be handled visually or in form 
> submission. Once you've tried to understand the complexity 
> involved we'll have more common ground for the discussion.

Unfortunately, this aspect is not my highest priority.  The unfortunate
thing is I'll probably just have to knowingly generate invalid HTML in some
cases because I know the browsers will handle it, as will so many others who
are using semantic markup in HTML who bump into the limitations imposed by
the specification writer.  FWIW.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/

Re: [whatwg] Semantic styling languages in the guise of HTML attributes.

2007-01-03 Thread Hallvord R M Steen

On 01/01/07, Mike Schinkel <[EMAIL PROTECTED]> wrote:

> Interesting that you should choose that example, because
> it can mean different things depending on the element you use
> it on. Therefore, a global |type| attribute would almost
> certainly conflict with the element-specific attribute unless
> it was defined otherwise.

Conflicts don't create any anxiety for me. If there is a conflict either
there is an undefined state or one of the two is defined to take
prescedence.

Right. Do you volunteer for the job of going through all "role" values
and all current HTML element semantics and define which one takes
presedence in each possible conflict? Matthew's point is that this
task itself is massive. Imagine: for each suggested "role" value, go
through all HTML elements (since "role" is a global attribute) and
note possible conflicts. Go through all other HTML attributes (and
their values) and note possible conflicts. Now define the outcome of
each conflict. Do it again, but now in C++ code.
His secondary point is that if the spec doesn't do this, every browser
will handle things differently so authors will not be able to use
"role" as intended because of browser incompatibilities.

> I've shown you that not only are there conflicts with
> proposed attributes, roles and elements, but that they
> actually compete in certain situations. Furthermore, I did so
> with only minutes worth of research.

I don't see that as a problem they way you do.

That's the attitude that made HTML error recovery such a mess :-(

 you have an opinion that few if any others are rallying behind.

Perhaps because it seems too obvious to discuss?
You could go back to the list of markup samples, and tell us for each
of them what you feel the actual semantic of that should be, and how
it should be handled visually or in form submission. Once you've tried
to understand the complexity involved we'll have more common ground
for the discussion.

--
Hallvord R. M. Steen

Re: [whatwg] and

On Wed, 03 Jan 2007 11:08:29 +0100, Benjamin Hawkes-Lewis  
<[EMAIL PROTECTED]> wrote:

| 
|   
| rhubarb rhubarb rhubarb
| [Nemo, Works, IV]
|   
| 


That's much better. :)


Making quoting even more difficult is not better at all in my opinion.


--
Anne van Kesteren

Re: [whatwg] and