Re: [whatwg] Thesis draft about HTML5 conformance checking

[Ian Hickson]

On Mon, 12 Mar 2007, olivier Thereaux wrote:
> 
> Did you have a chance to look at engines in authoring tools? What type of
> parser do NVU

Gecko, same as Firefox.


> Amaya,

Amaya's editor uses the same rendering engine as Amaya's browser, which I 
presume was ignored due to its negligible market share.


> golive etc work on?

Golive uses Opera's rendering engine.


> How about parsing engines for search engine robots? These are probably 
> as important, if not more as some of the browser engines in defining the 
> "generic" engine for the web today.

Search engine companies are notoriously secretive about what their 
indexing pipelines support, since any insight into how they work can be 
abused by people attempting to game their ranking algorithms. The WHATWG 
specification (in particular the parsing part, but other parts as well) 
has, however, been influenced by what information search engine 
implementors have confidentially contacted me with, and what suggestions 
they have anonymously or subtly sent to the list over the years. (This is 
why a careful study of the specification's acknowledgements will reveal 
employees from several search engine implementors.) In any case, reverse 
engineering search engine indexing pipelines is extremely difficult and 
tedious, orders of magnitude more so than even browsers.

Why do you think search engine behaviour is more important than browser 
engine behaviour? For what it's worth, search engine engineers I have 
spoken to have told me that what browsers do is far more important than 
what a particular version of a search engine does in terms of what the 
specification should say, because their results are better when their 
algorithms match the browsers' behaviours.

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

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Robert Brodrecht]

On Mar 11, 2007, at 4:39 AM, Mihai Sucan wrote:

It's false to assume the UA developers can happily say "now we'll  
parse HTML5, lets use our new HTML5 parser". No, this won't happen.  
Here's why: the UA cannot be sure that the document is *really*  
HTML 5.


Browsers don't read DTDs.  They wouldn't read the link  
rel="recommedation" src="url-to-html-document".  It would exist to  
commit the author of the document to a certain recommendation, and,  
in the future, let other authors know what the author was working  
with.  Like DTDs but for humans instead of programs.  The browsers  
would continue to do whatever they feel like they need to do to  
render the content.


So, I ask you: what use is then a DTD, a version attribute, or any  
indication that the document is written with HTML5 in mind? It's  
practically useless. The UAs will completely ignore it, if it would  
exist (at least for the moment - the future is still subject to  
change :) ).


Web standards are about committing to ideals.  It would serve the  
purpose of committing the author to a certain ideal (e.g. WHATWG's  
HTML 5 standards) and, in the future, let other authors know what the  
author was intending to do.  I don't see this as differing much from  
link rel="author" and link rel="license". [1]  It'd be an optional  
tag for those of us who want to let people know exactly what we were  
trying to do with the document.


I think it's too early to talk about W3C HTML5 versus WHATWG HTML5.  
We shall wait and see.


Some people don't save money in the event that they get laid off from  
their job.  All I'm saying is that a contingency plan won't hurt  
anything.  We have a competing standard now.  The fact that the  
WHATWG exists suggest that we could have more competing standards.   
Before, it was OK to act as though the WHAT HTML 5 was the only HTML  
5 because it was the only HTML 5.  By the time W3C finishes their  
recommendation, there will be two HTML 5s. I will be very surprised  
if W3C and WHAT create two completely compatible recommendations.   
I'm worried that the new browser wars to be recommendation wars...
Things are suddenly different now than they were before.  Talking  
about it now before it is a problem sure beats having to hack around  
it after it is a problem (see the original quirksmode switch and the  
fact that IE team now wants another quirksmode switch).


I don't remember them *asking* a WG for such solutions. This is  
only a proposal made by the initial author of the thread.


Microsoft didn't ask a standards group for a solution.  They asked  
developers for another standards mode opt-in. [2]  Presumably, the  
opt-in would be something in one of the new recommendations that is  
different from HTML 4.  That would fall on WHAT WG and W3C WG.  The  
header I suggested would put it in the hands of IE instead of in the  
hands of a specification.  Then it isn't about the specification.   
It's about some proprietary thing Microsoft needs for their browser  
to work better for us.  All they want is some way to tell their  
browser to use super-standards mode.  There really is no reason to  
put this switch in HTML 5.  The header could be called "X-IE-SUPER- 
STANDARDS-MODE: On;" to solve the problem.  My example was written  
how it was before ("X-STANDARDS-MODE: HTML5") to give Microsoft a  
little more leeway if they needed yet another switch in the future  
(as some on this list feel they may).  It really doesn't matter what  
the header is.  What matters is that it means WHAT doesn't need to  
add some proprietary thing to their recommendation to fix IE's problems.


[1] http://www.whatwg.org/specs/web-apps/current-work/#linkTypes
[2] http://video.yahoo.com/video/play? 
vid=cccd4aa02a3993ab06e56af731346f78.2006940 or http:// 
us.dl1.yimg.com/download.yahoo.com/dl/ydn/yui/theater/ 
browserwars-20070228.m4v (18:49 is where Chris Wilson actually says  
the line in question; the monologue that leads to the question starts  
around 15:00 )

--
Robert 

Re: [whatwg] href attribute

[Daniel Glazman]

On 11/03/2007 22:16, Matthew Raymond wrote:


   Why? A hyperlink is a relationship BETWEEN to anchors.


No. Between two resources. Resources can be anchors inside
document instances.

Re: [whatwg] href attribute

[Daniel Glazman]

On 11/03/2007 21:30, Anne van Kesteren wrote:

What does ... not offer that href="">... does? 


Code quality... The former is just ugly, really ugly, it smells like
HTML+ from 1993.

Re: [whatwg] Thesis draft about HTML5 conformance checking

[olivier Thereaux]

On Mar 11, 2007, at 02:15 , Henri Sivonen wrote:

The draft of my master's thesis is available for commenting at:
http://hsivonen.iki.fi/thesis/


Henri, congratulations on your work on the HTML conformance checker  
and on the Thesis. It's been a truly informative and enlightening  
reading, especially the parts where you develop on the (im) 
possibility of using only schemas to describe conformance to the  
html5 specs. This is a question that has been bothering me for a long  
time, especially as there is only one (as of today) production-ready  
conformance checking tool not based on some kind (or combination) of  
schema-based parsers, and although, as it is often pointed out, no  
browser uses a DTD-based parser in their engine today, I still think  
producing a schema representation of (most of) the conformance  
criteria help adoption and implementation.



Some comments based on first read through the thesis, below.
I'm cross-posting them to the www-validator list at w3c, as I think  
your thesis will be of interest to a number of subscribers of that  
list too.

For www-validator, Henri's announcement and rfc -
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/ 
009941.html




[2.3.2] I share the view of the Web that holds WebKit, Presto,  
Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox  
and IE, respectively) to be the most important browser engines.


Did you have a chance to look at engines in authoring tools? What  
type of parser do NVU, Amaya, golive etc work on?
How about parsing engines for search engine robots? These are  
probably as important, if not more as some of the browser engines in  
defining the "generic" engine for the web today.



[4.1] The W3C Validator sticks strictly to the SGML validity  
formalism. It is often argued that it would be inappropriate for a  
program to be called a “validator” unless it checks exactly for  
validity in the SGML sense of the word – nothing more, nothing less.


That's very true, there's a strong reluctance from part of the  
validator user community tool to do anything else than formal  
validation, mostly (?) out of fear that it would eventually make the  
term of "validation" meaningless. The only thing the validator does  
beyond DTD validation are the preparse checks on encoding, presence  
of doctype, media type etc.


I think it will change over time, in fact it's already changing, as  
the innards of the validator have moved to a SAX-based parsing. It's  
going to be an opportunity to add data type checking and move closer  
to conformance checker than validator. Work at W3C on Unicorn [1] and  
little modules such as the Appendix C checker [2] for XHTML1.0 also  
go in that direction.


[1] http://www.w3.org/QA/Tools/Unicorn/
[2] http://dev.w3.org/cvsweb/perl/modules/W3C/XHTML/HTMLCompatChecker/



[6.1.3] Erroneous Source Is Not Shown
The error messages do not show the erroneous markup. For this  
reason it is unnecessarily hard for the user to see where the  
problem is.


Was this by lack of time? Did you have a look at existing  
implementations? Oh I see [ 8.10 Showing the Erroneous Source Markup]  
as future work. If you're looking for a decent, though by no means  
perfect, implementation, look for sub truncate_line  in

http://dev.w3.org/cvsweb/~checkout~/validator/httpd/cgi-bin/check
(this is to be modularized out of the check script and into a cpan  
module sooner or later, see [3])


[3] http://esw.w3.org/topic/SoftwareProjects


[6.2] Instead of modifying the libraries themselves, an alternative  
approach to localization would be reverse templating. The English  
messages would be matched against known patterns that would allow  
the variable parts to be extracted. The variable parts could then  
be plugged into a translated message corresponding to the matched  
pattern.


This is something I have been looking at, and had come to the same  
conclusion. I'm hoping to be able to reuse, in one way or another,  
the existing localization of some of the libraries being used (e.g.  
OpenSP, with all its issues, has a very impressive localization record).



[8.1] Even though the software developed in this project is Free  
Software / Open Source, it has not been developed in a way that  
would make it easily approachable to potential contributors.  
Perhaps the most pressing need for change in order to move the  
software forward after the completion of this thesis is moving the  
software to a public version control system and making building and  
deploying the software easy.


Making it available on a more open-sourcey system, with a multi-user  
revision system will probably not create an explosion of code  
contributors (you've had very helpful contributions from e.g Elika,  
and most OS projects, even successful ones, never have more than a  
handful of coders), but you may be able to create a healthy community  
of users, reviewers, bug spotters, translators, document editors,  
beyond

Re: [whatwg] [html5] Typo in 3.7.5.3. Pragma directives

[Ian Hickson]

On Fri, 9 Mar 2007, Mihai Sucan wrote:
>> 
> Reading about the  element I found a typo in the "Pragma directives"
> section, Refresh state. [1]
> 
> "If another meta element in the Refresh state has already been successfully
> processed (i.e. when it was inserted the user agent processed it and reached
> the last step of this list of steps), then abort steps steps."
> 
> I think that needs to be changed to:
> 
> "If another meta element in the Refresh state has already been successfully
> processed (i.e. when it was inserted the user agent processed it and reached
> the last step of this list of steps), then abort these steps."
> 
> [1] http://www.whatwg.org/specs/web-apps/current-work/#pragma

Fixed, thanks.

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

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Ian Hickson]

On Sun, 11 Mar 2007, Matthew Ratzloff wrote:
> On Sun, March 11, 2007 3:20 pm, Anne van Kesteren wrote:
> >
> > There needs to be versioning? The web has done great so far without 
> > it... I'm not sure I really see the need.
> 
> The Web has done great so far without it?  When "strict" mode was 
> introduced, all existing websites didn't suddenly start rendering under 
> it.  It was opt-in.  Versioning is just a formalized way of opting into 
> a certain rendering method.

Strict mode isn't versioning, per se; it's a toggle between two modes 
which was basically required to get around the problem of the standards 
not lining up with reality and the browsers being unable to both comply to 
standards and render legacy content.

HTML5 doesn't need such a rendering mode flag because it doesn't introduce 
incompatibilities (by design).

As a rule, versioning is a very bad design strategy. Implementors are 
forced to support every version that is used by content. If versions are 
different from each other, then that basically means a new implementation 
per version. If there are five versions, then browser vendors end up 
having to support five browsers instead of one. Given how much difficulty 
browser vendors have supporting just the one browser (or one-and-a-bit, 
with quirks mode), I would hate to force them to support, over the years, 
dozens of different versions.


> It would be great if rendering always stayed the same, browser makers 
> always got it right the first time, and things were only added to the 
> specification.  But as I mentioned previously, without versioning of 
> some sort, rendering either becomes a moving target or browser makers 
> become slaves to backwards compatibility.  Or, more likely, some 
> combination of both.

The basic design principles of the WHATWG:

   http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html

...assumes that backwards compatibility will be supported above all else. 
(It's the first thing listed, even.)

I don't see what you describe as a problem, but as a strength.

Sure, it's less "pure", but it is far more pragmatic, and far more likely 
to actually work and remain maintainable on the long term.

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

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Matthew Ratzloff]

On Sun, March 11, 2007 3:20 pm, Anne van Kesteren wrote:
> There needs to be versioning? The web has done great so far without it...
> I'm not sure I really see the need.

The Web has done great so far without it?  When "strict" mode was
introduced, all existing websites didn't suddenly start rendering under
it.  It was opt-in.  Versioning is just a formalized way of opting into a
certain rendering method.

It would be great if rendering always stayed the same, browser makers
always got it right the first time, and things were only added to the
specification.  But as I mentioned previously, without versioning of some
sort, rendering either becomes a moving target or browser makers become
slaves to backwards compatibility.  Or, more likely, some combination of
both.

By introducing a version attribute, browser makers can have a rendering
engine for HTML 4.01, one for HTML 5, one for HTML 6, and so on (or
really, one rendering engine with differences extended off of it).  This
way, users are required to transition to newer forms of HTML if they want
access to new tags, which also means no longer using deprecated tags (with
something like a one-version transitional period).  If you want access to
, you have to give up  at some point.  And no one is
ever required to update their old sites to get them to render correctly.

This seems especially important with deprecation or with tags that change
usage between versions.

Of course, this requires lots of communication between browser makers and
standards bodies.

-Matt

Re: [whatwg] canvas elements etc

[ddailey]

I have had no interest in learning (or teaching) about the Canvas tag since, 
from what I can see, it is quite impoverished relative to SVG. And, to boot, 
it is not universal across browsers. The browsers that support Canvas, 
pretty much already do support, or seem to be close to supporting SVG.


The one advantage that VML had over SVG,  was the ease of co-integration of 
it with HTML (albeit in precisely one browser). If Canvas can be 
standardized as a place for drawing SVG, then I can deliver a million votes 
(plus or minus a million) to the the party that adopts it in its platform.


I know... nobody cares about a million votes any more.

ddailey

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

To: "Matthew Raymond" <[EMAIL PROTECTED]>
Cc: ; "carmen" <[EMAIL PROTECTED]>
Sent: Sunday, March 11, 2007 5:47 PM
Subject: Re: [whatwg] canvas elements   etc



On Sun Mar 11, 2007 at 05:06:06PM -0400, Matthew Raymond wrote:

carmen wrote:
>  are there plans to support html style creation of elements within the
 tag?

   How would that be different from Scalable Vector Graphics (SVG)???


thats kind of what i'm asking, it looks like SVG has its own API already, 
sort of similar to canvas. are there plans to merge? can you use svg 
elements inwide a canvas element or will the browser not find them? are 
there plans for that to change? etc.


i guess a roadmap explaining the relationship between  and .. 
is this another xhtml2 vs html5, simultaneous development? what was wrong 
with SVG that required a simpler replacement (but i guess not element 
level interface)..


anyways, i guess i'lll scour faqs and unsubscribe

Re: [whatwg] href attribute

[Andrew Fedoniouk]

- Original Message - 
From: "Anne van Kesteren" <[EMAIL PROTECTED]>

To: "Daniel Glazman" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>
Sent: Sunday, March 11, 2007 11:52 AM
Subject: Re: [whatwg] href attribute


On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman 
<[EMAIL PROTECTED]> wrote:
In any case not all 's are hyperlinks so for your meaning of 
semantic they should also not be automatically hyperlinks (or anchors 
if you wish). I am pretty sure that existence of 'href' attribute is 
what creates semantic meaning of  for you. So why  cannot be href> or ?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)


I agree. One of the reasons HTML5 has  and redefined -.



Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.


What are the problems it solves? To my mind introducing it will just break 
compatibility and complicate implementations for no apparent benefit. You 
also get to deal with silly cases like:


There are many cases when hyperlink-head needs to be a block level
element. Not all contexts in html allow inline elements to appear.
And , as inline element, by itself cannot contain block elements.
Example #1
... is not acceptable.
... is not acceptable.

Example #2

  ...

in this example the desire is to declare the whole rectangle of li to be
a link, not just textual portion of it.  Think about tabs implementation
where each tab is a rectangle with clear visual borders. human
would expect that the whole area inside the borders (included)
of the tab  is a clickable area.

"... and complicate implementations..."

I do not know of how this is implemented in Opera but in my
case to support href globally is a matter of changing:
 a:link { behavior: hyperlink; }
to
 :link { behavior: hyperlink; }
in master style sheet.

I beleive that each modern and modular UA has similar
mechanism of assigning "behavior handlers".



  http://www.opera.com/>



Think about this:

http://www.opera.com/help/checkbox/explanation
 target="_new">
links like this can be used for contextual help and for me is perfectly 
valid

use case.

It is matter of UA implementation of how to support multiple behaviors
on the same element but it is feasible.

Andrew Fedoniouk.
http://terrainformatica.com




HTML5 already redefines  to be hyperlink or a placeholder for one (this 
should address your concern raised in another e-mail). The idea of name=""> is not mentioned in the draft and isn't even conforming (although 
I suppose user agents will be required to support it). Any element can be 
a link target much like in HTML4.



--
Anne van Kesteren

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Anne van Kesteren]

On Sun, 11 Mar 2007 06:40:18 +0100, Matthew Ratzloff  
<[EMAIL PROTECTED]> wrote:
I don't care about DTD, but DOCTYPE is established, so it seems strange  
to trash it in favor of something new when the benefit is questionable  
(as

far as I can tell).  It is also evident to me that there needs to be some
kind of versioning--consistent rendering shouldn't be a moving target.


There needs to be versioning? The web has done great so far without it...  
I'm not sure I really see the need.




If DTD is out, bring back the deprecated "version" attribute that it
replaced.  Assuming there is only one version of HTML 5.0, the following
would work:


...


All attributes optional, obviously.


What exactly would this help with? (I might be convinced that a  
meaningless version="" attribute is useful for conformance checkers. To  
make conformance not a moving target. However, given that other  
interpreting software, such as web browsers, do change, maybe conformance  
should too.)



--
Anne van Kesteren

Re: [whatwg] canvas elements etc

[carmen]

On Sun Mar 11, 2007 at 05:06:06PM -0400, Matthew Raymond wrote:
> carmen wrote:
> >  are there plans to support html style creation of elements within the
>  tag?
> 
>How would that be different from Scalable Vector Graphics (SVG)???

thats kind of what i'm asking, it looks like SVG has its own API already, sort 
of similar to canvas. are there plans to merge? can you use svg elements inwide 
a canvas element or will the browser not find them? are there plans for that to 
change? etc.

i guess a roadmap explaining the relationship between  and .. is 
this another xhtml2 vs html5, simultaneous development? what was wrong with SVG 
that required a simpler replacement (but i guess not element level interface).. 

anyways, i guess i'lll scour faqs and unsubscribe

> 

Re: [whatwg] href attribute

[Matthew Raymond]

Daniel Glazman wrote:
>> Indeed.  IMO, global |href| gives nothing but more confusion.  If we
>> want to have hyperlinks on block-level elements, it is simpler just
>> let  and/or other inline elements be legal to wrap block-level
>> elements.
> 
> No, it gives more than that : if |href| becomes global, the usage of
> |a| will decrease and that's a good thing. |a| is a bad element because
> it serves as source AND target of links, because it's not multivalued,

   How is that any different from this?...

| 

   In the above, it has an |id|, so it can be a destination. It has a
global |href| attribute, so it can be a source. Heck, it can link to
itself for that matter:

| 

> and I have 5 or six other very good reasons in mind.

   Hope they're better than that last one, especially when you consider
that |name| can't be a global attribute since it's already defined on
form control elements. (Not that I'm a huge fan of |name|. I'm just
pointing out that  can't be completely replaced by globalizing its
attributes.)

> Anything we can do
> to prepare a future - in the long term - deprecation of |a| is a good
> thing for the future of HTML.

   I have yet to hear a convincing argument in that regard.
Specifically, I have yet to hear any semantic advantage to a global
|href| attribute. In my eyes, this is all just frivolous markup
restructuring.

Re: [whatwg] href attribute

[Matthew Raymond]

Andrew Fedoniouk wrote:
>>   This is not a definition of the  element. In fact,  is defined
>> as a anchor, not a hyperlink.
> 
> I think "hyperlink" is better in any sense 
> than "anchor" as a designation of this entity.

   Why? A hyperlink is a relationship BETWEEN to anchors. It can't be an
element any more than a journey can be considered a place.

> I beleive that you and me have different interpretation of 
> the term 'semantic'. 
> 
> For my semantic any HTML element that has 
> "href" attribute is not anyhow different from the  element
> with href.

   What you're creating is a new attribute that happens to have the same
name as the HTML 4.01 |href| attribute, not an extension thereof. The
fact that it could be implemented in a manner identical to  is a
function of implementation, not semantics.

> If I see  I recognize that this is a list item that
> leads somewhere.

   That's not saying much, because you already know how to use  and
are familiar with its attributes.

> Exactly (and even better) as ...

   No it's not, because if I want to move the anchor out of the list,
I'd have to create a new container element in your markup, whereas the
HTML 4.01 equivalent requires a mere cut and paste (or perhaps a
drag-drop, depending on your editor).

> For different tools it also does not matter what to use:
> 
> getElementsBySelector(":link") or 
> getElementsBySelector("a:link") or 
> getElementsBySelector("[href]") or 
> whatever.

   If you want to use the Selectors API:

| document.matchAll("[href]")

   However, my point was never that you couldn't find a newly defined
attribute with a newly defined DOM API...

> In any case not all 's are hyperlinks so 
> for your meaning of semantic they should also not be 
> automatically hyperlinks (or anchors if you wish).  

   An  element is always an anchor. It's simply not specified whether
or not it's a source or a destination. No element can be a hyperlink, by
the definition you provided in your earlier post, because a hyperlink is
a relationship between anchors.

> I am pretty sure that existence of 'href' attribute is 
> what creates semantic meaning of  for you. 

   The |href| attribute doesn't define anchors. It defines the
relationship between those anchors. It does imply that the anchor is a
source, but the actual anchor semantic is at the element level.

> So why  cannot be  or ?

1) It makes the markup brittle when editing.

2) It makes markup harder to read by:

   a) Forcing you to look for an attribute that can very in position
  relative to the start of the element tag instead of a letter
  that's the very first character in the element tag.

   b) Forcing you to look for the starting tag in order to determine if
  an ending tag ends an anchor for a hyperlink.

3) It's not compatible with legacy browsers.

4) It causes confusion because authors might infer the meaning of the
   attribute based on the element it's declared on.

5) It may be non-trivial to add to some browser implementations.

Re: [whatwg] canvas elements etc

[Matthew Raymond]

carmen wrote:
>  are there plans to support html style creation of elements within the
 tag?

   How would that be different from Scalable Vector Graphics (SVG)???

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 09:30:58PM +0100, Anne van Kesteren wrote:
> On Sun, 11 Mar 2007 21:27:14 +0100, carmen <[EMAIL PROTECTED]> wrote:
> >suppose one is building a GUI with solely  elements. say you have a 
> >doorway, clicking on it opens into the room, which is another page. forcing 
> >this stuff into onclick() just because href= 
> >is invalid, decreases scrapability/accessibility. is one supposed to just 
> >wrap canvas polygons in s or something?
> 
> What does ... not offer that  href="">... does? And if this is in fact an application you might 
> actually want to have the  as fallback of the 

well i was thinking like . i guess its not that simple yet..

>  along with other content...
> 
> 
> --
> Anne van Kesteren
> 
> 
> 

Re: [whatwg] canvas elements etc

[carmen]

> suppose one is building a GUI with solely  elements.

i suppose i should have researched   - it looks like it doesn't have 
elemnts one might be faimilar with the Tk canvas - you can only draw using 
javascript. are there plans to support html style creation of elements within 
the  tag?

Re: [whatwg] href attribute

[Anne van Kesteren]

On Sun, 11 Mar 2007 21:27:14 +0100, carmen <[EMAIL PROTECTED]> wrote:
suppose one is building a GUI with solely  elements. say you  
have a doorway, clicking on it opens into the room, which is another  
page. forcing this stuff into onclick() just because href= is invalid,  
decreases scrapability/accessibility. is one supposed to just wrap  
canvas polygons in s or something?


What does ... not offer that href="">... does? And if this is in fact an application you might  
actually want to have the  as fallback of the  along with other  
content...



--
Anne van Kesteren

Re: [whatwg] href attribute

[carmen]

On Sun Mar 11, 2007 at 08:52:36PM +0100, Anne van Kesteren wrote:
> On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman <[EMAIL PROTECTED]> wrote:
> >>In any case not all 's are hyperlinks so for your meaning of semantic 
> >>they should also not be automatically hyperlinks (or anchors if you wish). 
> >>I am pretty sure that existence of 'href' 
> >>attribute is what creates semantic meaning of  for you. So why  
> >>cannot be  or ?
> >
> >Let me also play the devil (I love it) : a feature is not trashable
> >only because it comes from XHTML 2.0 :-)
> 
> I agree. One of the reasons HTML5 has  and redefined -.
> 
> 
> >Here, a global href is a really cool idea, we should have done it in
> >HTML 4 but we were too blind to see.
> 
> What are the problems it solves? To my mind introducing it will just break 
> compatibility and complicate implementations for no apparent benefit. You 
> also get to deal with silly cases like:

suppose one is building a GUI with solely  elements. say you have a 
doorway, clicking on it opens into the room, which is another page. forcing 
this stuff into onclick() just because href= is invalid, decreases 
scrapability/accessibility. is one supposed to just wrap canvas polygons in 
s or something?

> 
>   http://www.opera.com/>
> 
> 
> HTML5 already redefines  to be hyperlink or a placeholder for one (this 
> should address your concern raised in another e-mail). The idea of  name=""> is not mentioned in the draft and isn't even 
> conforming (although I suppose user agents will be required to support it). 
> Any element can be a link target much like in HTML4.
> 
> 
> --
> Anne van Kesteren
> 
> 
> 

Re: [whatwg] href attribute

[Anne van Kesteren]

On Sun, 11 Mar 2007 06:03:02 +0100, Daniel Glazman  
<[EMAIL PROTECTED]> wrote:
In any case not all 's are hyperlinks so for your meaning of  
semantic they should also not be automatically hyperlinks (or anchors  
if you wish). I am pretty sure that existence of 'href' attribute is  
what creates semantic meaning of  for you. So why  cannot be href> or ?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)


I agree. One of the reasons HTML5 has  and redefined -.



Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.


What are the problems it solves? To my mind introducing it will just break  
compatibility and complicate implementations for no apparent benefit. You  
also get to deal with silly cases like:


  http://www.opera.com/>


HTML5 already redefines  to be hyperlink or a placeholder for one (this  
should address your concern raised in another e-mail). The idea of name=""> is not mentioned in the draft and isn't even conforming (although  
I suppose user agents will be required to support it). Any element can be  
a link target much like in HTML4.



--
Anne van Kesteren

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Andrew Fedoniouk]

- Original Message - 
From: Robert Brodrecht

To: Andrew Fedoniouk
Cc: [EMAIL PROTECTED]
Sent: Sunday, March 11, 2007 1:49 AM
Subject: Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch



On Mar 10, 2007, at 11:03 PM, Andrew Fedoniouk wrote:
It is idealistic because, say, if you will put following in your 
.htaccess:

AddType foo/bar .html


If I "AddType application/xhtml+xml .html" to a .htaccess file, it causes 
browsers to interpret my html as XHTML.

...



Beg my pardon but did you try to do this on the server hosting 
robertdot.org?
It should not affect any headers. At least it was so last time I tried to do 
the same.


This is just a demonstration that use of headers is limited.

There are many other ways to deliver HTML content. Only one of them
is using http protocol (so headers).

E.g. access to content by ftp, HTML as a clipboard format in
cut-n-paste operations, DOMElement.setInnerHtml use, etc.

Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] Configure Apache to send the right MIME type for XHTML

[L. David Baron]

On Sunday 2007-03-11 18:26 +0100, Bjoern Hoehrmann wrote:
> * L. David Baron wrote:
> >My dismissal of XHTML is that the designers of XHTML and related
> >standards are repeatedly introducing more and more incompatibility
> >between XHTML and HTML, which makes it progressively harder for
> >authors to transition to XHTML (particularly to do so gradually on a
> >large site).
> 
> Out of curiosity, do you dismiss "HTML5" on the same grounds? As an
> example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is
> as close as it comes to a proper HTML document, but to turn it into
> a HTML5 document I would need to make many non-trivial changes, e.g.

The distinction here is that all of these are either removed
features or correctness of document semantics, and therefore don't
affect implementation behavior.  An implementation that implements
both HTML4 and HTML5 will handle all of them, and therefore authors
can transition gradually between the two (although they'll
technically not be conformant to either while doing so, and many may
well stay in that state permanently).

(The value of having these things as changes in HTML5 comes from
authors who use conformance checkers that will tell them to avoid
these bad practices, not from implementations behaving differently.)

-David

-- 
L. David Baronhttp://dbaron.org/ >
   Technical Lead, Layout & CSS, Mozilla Corporation


pgpl5KXWWV5cH.pgp
Description: PGP signature

Re: [whatwg] Configure Apache to send the right MIME type for XHTML

[Bjoern Hoehrmann]

* L. David Baron wrote:
>My dismissal of XHTML is that the designers of XHTML and related
>standards are repeatedly introducing more and more incompatibility
>between XHTML and HTML, which makes it progressively harder for
>authors to transition to XHTML (particularly to do so gradually on a
>large site).

Out of curiosity, do you dismiss "HTML5" on the same grounds? As an
example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is
as close as it comes to a proper HTML document, but to turn it into
a HTML5 document I would need to make many non-trivial changes, e.g.
find replacements for

  * 
  * 
  * empty  elements
  * 
  * 
  * 
  * 
  * 

and then

  * review whether I use any so-called predefined classes and if,
whether I use them correctly, or find out how to replace them

  * review whether I am MicroformatsOK according to the latest
Wiki pages

  * review whether my img elements are really some piece of text
with some alternate graphical representation

  * review whether my images are all the exact size given in the
height and width attributes

and so on, whereas switching to XHTML would simply be a matter of
running HTML Tidy on all the files and lowercasing the selectors
in the style sheets? It's a lot of work if I just want to add my
favourite "HTML5" feature to the page.
-- 
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/ 

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Mihai Sucan]

Le Sun, 11 Mar 2007 15:35:09 +0200, Daniel Glazman  
<[EMAIL PROTECTED]> a écrit:



Just as a reminder, and I am an old monkey in the world of standards
bodies, a standard body is not only a cool place where friendly geeks
meet, drink (sometimes) free beer, and write standards for the beauty
of standards.

A standards body is a battlefield, where organizations want to push
THEIR OWN competitive advantage, be the first one to blabla, the best
one to blabla, where they hope to be THE solution's provider when
multiple solutions are on the table because THEY can implement it before
others.


I am sure of that. Everyone wants to push its own competitive advantage.  
That's good, as long as several ones "win" the battle (not only one "wins"  
everything) - otherwise we would really end having a monoculture.



As a reminder too, the IE team went from /dev/null to A BIG TEAM.


Going from /dev/null to A BIG TEAM is sure great, but there's a bit of  
salt in that: it's disappointing the fact they had no team at all for IE.



Last point, without IE, CSS wouldn't be what it is today. Without IE,
many W3C standards including the DOM would not be what they are today.
I can't count how many clever ideas Microsoft submitted to W3C WGs.


I know this piece of web browsers history.

Ironically, yes, Microsoft did push many innovative ideas into the Web,  
and then they abandoned the Web in 2001-2. Probably this is what annoys me  
most (and others as well): they abandoned the Web, leaving us with a buggy  
implementations of CSS, DOM, HTML, etc. I find it somewhat "outrageous" to  
have to spend days (and some spend nights as well) just to make a site  
work in IE - just because it has a huge market share. It is for *that*  
reason alone we are most tired of it.


And because Microsoft stopped improving IE, more and more web sites  
continued to rely on the bugs.



Please stop seeing the Great Evil Empire or you won't be able to
sit with them at a standardization table...


Agreed.

We will have to wait and see what the big team will do for IE.next.


--
http://www.robodesign.ro
ROBO Design - We bring you the future

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Daniel Glazman]

On 11/03/2007 13:11, Mihai Sucan wrote:

Yes I understand that, however I am skeptical about Microsoft Internet 
Explorer. I do not really believe they stopped wanting to dominate the 
web browsers market, and suddenly they'll just make a good web browser. 
They will create lockins, traps, and other tricks, to lock beginners in 
a Microsoftish World Wide Web.


Until further proof, I shall maintain my stance.

IE 7 is not such proof. It would have been a good start, in 2002-2003.


Just as a reminder, and I am an old monkey in the world of standards
bodies, a standard body is not only a cool place where friendly geeks
meet, drink (sometimes) free beer, and write standards for the beauty
of standards.

A standards body is a battlefield, where organizations want to push
THEIR OWN competitive advantage, be the first one to blabla, the best
one to blabla, where they hope to be THE solution's provider when
multiple solutions are on the table because THEY can implement it before
others.

And yes, same thing for the WHAT-WG modulo the fact browser vendors
are in good agreement here.

Standardization is a rather fair game, despite of being sometimes
a violent one, and Microsoft is like others here.

As a reminder too, the IE team went from /dev/null to A BIG TEAM.
Even if IE7 is not what many would call a "2007 browser", it's still
pushing the community and forcing us to remain active and reactive.
Diversity is good for the web ecosystem. IE7 is most welcome.

Last point, without IE, CSS wouldn't be what it is today. Without IE,
many W3C standards including the DOM would not be what they are today.
I can't count how many clever ideas Microsoft submitted to W3C WGs.

Please stop seeing the Great Evil Empire or you won't be able to
sit with them at a standardization table...

[whatwg] The input stream issues

[Geoffrey Sneddon]

From implementing parts of the input stream (section 8.2.2 as of  
writing) yesterday, I found several issues (some of which will show  
the asshole[1] within me):


	- Within the step one of the get an attribute sub-algorithm it says  
"start over" – is this start over the sub-algorithm or the whole  
algorithm?
	- Again in step one, why do we need to skip whitespace in both the  
sub-algorithm and at section one of the inner step for  tags?
	- In step 11, when we have anything apart from a double/single quote  
or less/greater than sign, we add it to the value, but don't move the  
position forward, so when we move onto step 12 we add it again.
	- In step 3 of the very inner set of steps for a content attribute  
in a  tag, is charset case-sensitive?
	- Again there, shouldn't we be given unicode codepoints for that (as  
it'll be a unicode string)?


- Geoffrey Sneddon

[1]: http://diveintomark.org/archives/2004/08/16/specs

Re: [whatwg] Thesis draft about HTML5 conformance checking

[mozer]

Ach Mensch !!
Two in a row !!

Hope the last two would help...

Thanks David²

On 3/11/07, David Håsäther <[EMAIL PROTECTED]> wrote:

mozer wrote:

> [[
> common.inner.strict-inline =
>   ( text )
> ]]
> appear twice in the html file

If you're referring to "5.6.2.1 Common Content Models", it's
"...strict-inline" and "...struct-inline" (unless this has been fixed
since you read it).

--
David Håsäther

Re: [whatwg] Thesis draft about HTML5 conformance checking

[David Håsäther]

mozer wrote:


[[
common.inner.strict-inline =
  ( text )
]]
appear twice in the html file


If you're referring to "5.6.2.1 Common Content Models", it's  
"...strict-inline" and "...struct-inline" (unless this has been fixed  
since you read it).


--
David Håsäther

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Mihai Sucan]

Le Sun, 11 Mar 2007 02:45:18 +0200, Alexey Feldgendler  
<[EMAIL PROTECTED]> a écrit:


Not necessarily. For a long time, Microsoft has been in a position where  
they benefit from the lack of interoperability with other browsers. They  
had no incentive to make their browser standards-compliant. Now times  
have changed, and even Microsoft, as far as I understand, is now willing  
to improve their standards compliance. So I don't think that the  
standards-mode story will repeat -- this happened before due to browser  
wars, where interoperability has been broken intentionally.


Yes I understand that, however I am skeptical about Microsoft Internet  
Explorer. I do not really believe they stopped wanting to dominate the web  
browsers market, and suddenly they'll just make a good web browser. They  
will create lockins, traps, and other tricks, to lock beginners in a  
Microsoftish World Wide Web.


Until further proof, I shall maintain my stance.

IE 7 is not such proof. It would have been a good start, in 2002-2003.

Instead of using this DOCTYPE switch, I was even thinking of  
conditional comments, DOM document property, etc. Yet, other methods  
only add complications. If Microsoft considers adding a new rendering  
mode as a must, such that it will not break many sites, then this  
DOCTYPE is an elegant solution. History will repeat itself, no matter  
how elegant the solution might be.


Conditonal comments and similar approaches solve another kind of  
problem: how to allow making pages which do the right thing in good  
browsers but still function in older browsers. OTOH, the DOCTYPE switch  
allows the browser to do the right thing for good pages without breaking  
the old pages.


Hence I consider the  a good and elegant solution for  
switching to the "strict standards mode" (even if I do not support it). I  
do not like the other proposals in this thread.



--
http://www.robodesign.ro
ROBO Design - We bring you the future

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Mihai Sucan]

Le Sun, 11 Mar 2007 02:37:30 +0200, Matthew Ratzloff  
<[EMAIL PROTECTED]> a écrit:



Relying on headers is a good way to get people to ignore that part of the
specification.  Web designers don't want to worry about headers and
.htaccess files.  It has to be syntactic.


Agreed.



I don't understand what's wrong with DOCTYPEs, myself.

http://www.w3.org/TR/html4/strict.dtd";>
http://www.whatwg.org/dtd/html5/strict.dtd";>
http://www.w3.org/TR/html5/strict.dtd";>
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>

The seem to serve the purpose.  If there are two HTML 5 specifications,
browser makers can come together to decide which one to support by  
default

when no DOCTYPE is present.  Developers who would prefer the alternate
standard could use the appropriate DOCTYPE.


Hmm... What's the use of a DTD if no UA cannot rely on it? If no UA will  
verify the code against the DTD, if no UA will even download it?


I don't know why... but I have the impression some of the people  
participating in this discussion want a DOCTYPE DTD just like they want a  
 atrtibute. This simply means that the DOCTYPE definition,  
by itself, is stripped by all technical value (the value of defining a  
DTD), changing its role to a simple tag/line for "informing" the UA and  
human code readers about the intentions of the author: "I sing HTML5".




-Matt


Hello Matt :). I think you miss quoted me. This is *not* what I said:


On Mar 10, 2007, at 8:38 AM, Mihai Sucan wrote:

We're already using headers to swap between HTML and XHTML (since we
still call both .html files).  Headers are for telling user agents
how to deal with content.  It seems like sending a header "X-
STANDARDS-MODE: HTML5;" (or "WHATWG-HTML5" if W3C's HTML 5 is
significantly different) or setting an http-equiv meta tag to tell IE
to use their super-standards mode is cleaner and more desirable as it
doesn't bloat the spec, and should be more than enough for them.  If
their standards mode for HTML5 has flaws and they need a NEW switch,
it can be changed to "X-STANDARDS-MODE: HTML6;" or whatever the
latest version of HTML is.  This can be set across an entire server
in a few seconds via config files if needed, or set on a single
folder via .htaccess files.  If headers are used, that also doesn't
bloat the file if is is saved on someone's HDD.


That was actually said by Robert Brodrecht. :)




--
http://www.robodesign.ro
ROBO Design - We bring you the future

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Mihai Sucan]

Le Sun, 11 Mar 2007 00:51:30 +0200, WHATWG <[EMAIL PROTECTED]> a écrit:


On Mar 10, 2007, at 8:38 AM, Mihai Sucan wrote:


There's no way to advertise the document as HTML 5, and it's
certainly not the purpose of the specification to do so.


This is a problem.  It is especially a problem now that the W3C is
working on their version of HTML 5.  When I asked Ian Hickson how
WHATWG would handle divergence in the W3C spec [1], he said he
"intended to make every effort to keep the two in sync." [2]  While I
appreciate his effort and I fully believe that he will do his best,
we are dealing with a body (i.e. the W3C) who have a history of
stubbornness and unwillingness to work with important members of the
community. [3]  The future is still undecided, but I don't think it
is a good idea to operate under the assumption that the W3C will copy
and paste the entire WHATWG HTML 5 spec.


Yes, this is going to be very interesting. If we will end-up having two  
separate HTML 5 specs, then The Web will be at loss. Stubborness should  
not have any place in HTML 5.



It seems the WHATWG is staunchly against DTDs, even if it has an
appropriate use (e.g. emails in this thread talking about XML
entities).  I've mulled over this awhile.  Since DTDs aren't
normative in browsers, perhaps a "link" element with a
"rel=specification" and an "href=http://www.whatwg.org/specs/web-apps/
current-work/" (for example) would be a new way to say, "this is the
specification I used to create this document."  It is easier to
remember than the DOCTYPE DTDs on pervious versions of HTML, and it
is much more human-readable than DTDs.  It addresses my concerns, and
doesn't use DTDs.


No, adding yet another way to inform the UA about the type of document is  
not good. So, no, I don't think using HTTP headers, or "link" elements, is  
good.


Let me make some points.

Say we have the version attribute, as suggested, on the  tag (the  
root tag), or we have the suggested HTTP header, or we have the "link"  
element, or a specific DTD, or whatever - it doesn't really matter. It's  
false to assume the UA developers can happily say "now we'll parse HTML5,  
lets use our new HTML5 parser". No, this won't happen. Here's why: the UA  
cannot be sure that the document is *really* HTML 5. The UAs (most notably  
the web browsers: Opera, Gecko, Safari, I-Etc), will continue to use their  
wild guessing technniques, their error recovery algorithms, and parsing  
rules. If they encounter supported tags/attributes/code defined in the  
HTML5 spec, they'll just use them. This is happening today in Opera 9: the  
Web Forms 2 implementation does not use any versioning, any specific DTD.  
The UA does not need to know if the document will contain WF2 or not.  
However, if it does find  then *that* will be used.  
Same goes for HTML5.


Also, web developers will never be able to rely on the fact that UAs will  
stop parsing the document if HTML5 is not supported (heck, that's not the  
purpose, *we* actually want older browsers to be able to use new HTML5  
documents). Next, web developers cannot expect that the UA will support  
all the HTML5 features. For example, they'll still need to check for the  
existence of each new DOM property/method.


So, I ask you: what use is then a DTD, a version attribute, or any  
indication that the document is written with HTML5 in mind? It's  
practically useless. The UAs will completely ignore it, if it would exist  
(at least for the moment - the future is still subject to change :) ).


By adding such indications we only create false expectations to  
beginners/noobs/non-experts.  They will create broken pages that rely on  
such indications.




Now, I don't know if it can be used as a quirksmode switch.  The
DOCTYPE seems like an ideal place to run the switch.  The problem
will be if the W3C (or some other as yet unformed working group that
decides to fork HTML) doesn't implement a DTD-less DOCTYPE.  If the
switch is the WHATWG HTML5 DOCTYPE, documents authored under W3C HTML
5 spec will not render in super-standard mode.  Browsers will have to
have multiple super-standards modes switches depending on what
version of HTML5 the author uses.


I think it's too early to talk about W3C HTML5 versus WHATWG HTML5. We  
shall wait and see.



IE asking a working group to provide some new way to specify
standards mode doesn't make sense.  That is an implementation problem
that they need to figure out.  It isn't our job to write their
software.  WHATWG doesn't need to bloat the spec for them.  The IE
team needs to be creative and find a solution to their problem.


I don't remember them *asking* a WG for such solutions. This is only a  
proposal made by the initial author of the thread.


Agreed, Microsoft needs to be creative (not evil) and find a solution.


We're already using headers to swap between HTML and XHTML (since we
still call both .html files).  Headers are for telling user agents
how to deal with content.  It 

Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

[Robert Brodrecht]

On Mar 10, 2007, at 11:03 PM, Andrew Fedoniouk wrote:
It is idealistic because, say, if you will put following in  
your .htaccess:

AddType foo/bar .html


If I "AddType application/xhtml+xml .html" to a .htaccess file, it  
causes browsers to interpret my html as XHTML.  Browsers might ignore  
unknown types, but, at least with HTML, serving it with a different  
type DOES make a different.  If I add a no-cache or expires header  
via the PHP header(), the browser caches the file differently.  It  
might be idealistic to throw an unknown header and expect it to work,  
but if it is a header the browser knows, it will behave differently.   
IE is willing to add some Super-Standards Mode based on some new  
switch.  So, they will recognize the header.



Think about this: All UAs will correctly present file
some.png even it contains jpeg bits. Even if server reports image/x- 
png content-type for it.
It is very old tradition in software design - all file formats  
contain identification of the

content type in some form - usually first 256 bytes
is enough to determine type. So why html should be an exception of  
this rule?


UAs sniff headers.  WHATWG's HTML 5 is trying to kill off the DTD,  
which would be a good thing to sniff on, as I specified in the blog I  
posted about this very subject.[1]  What the WHATWG gives us is only  
a way to say "This is HTML" not "This is HTML 5" or "This is HTML  
6."  So, sniffing isn't possible as far as I can tell.  That is why  
it is an exception.


Furthermore, if we follow the spec, we will be fine for all things  
HTML 5 wants.  The DOCTYPE is new and unique.  For HTML 6, if we need  
to tell the browser something else, we can't.  There is no versioning.


This thread is about telling IE to turn on super standards mode.  (I  
combined some stuff that has been on my mind instead of starting a  
new thread.  As a newbie to this mailing list, I didn't want to over- 
step my bounds early on.  It's ended up with more confusion.)  IE's  
rendering modes have nothing to do with the HTML document itself, and  
everything to do with telling the browser how to handle the  
document.  It's not the responsibility of the recommendation to tell  
the browser what mode it needs to render in.  It's not in the W3C  
recommendation to use the DOCTYPE as a quirksmode switch in HTML 4.   
It was something that the browser vendors decided to do.  As I said  
before, I think it's a cop out for the IE team to ask for a new  
switch.  They should be creative and figure it out themselves.  My  
suggestion was for them to do something non-invasive to the HTML 5  
recommendation (look for a particular header) that would work even if  
W3C's recommendation is radically different from the WHATWG's.  It  
will be more universal, won't bloat the specs, will work better for  
what the IE team expects (something in addition to the doctype) and  
can be modified to whatever Microsoft decides it wants to be since it  
will be proprietary to their browser.


--
Robert 



[1] http://robertdot.org/2007/03/08/html-5-whatwg-versus-w3c.html

Re: [whatwg] href attribute

[Andrew Fedoniouk]

- Original Message - 
From: "Daniel Glazman" <[EMAIL PROTECTED]>

To: "Andrew Fedoniouk" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>; "Matthew Raymond" 
<[EMAIL PROTECTED]>

Sent: Saturday, March 10, 2007 9:03 PM
Subject: Re: [whatwg] href attribute



On 11/03/2007 05:59, Andrew Fedoniouk wrote:

In any case not all 's are hyperlinks so for your meaning of semantic 
they should also not be automatically hyperlinks (or anchors if you 
wish). I am pretty sure that existence of 'href' attribute is what 
creates semantic meaning of  for you. So why  cannot be  or 
?


Let me also play the devil (I love it) : a feature is not trashable
only because it comes from XHTML 2.0 :-)
Here, a global href is a really cool idea, we should have done it in
HTML 4 but we were too blind to see.




:)

BTW: I had a feeling that anchor is a name of region in html.
So  or  are
anchors but  or  are links
to some anchors.

But it seems that in such semantically saturated
place as whatwg mail list my used to be clear perception
of simple things like anchors was changed significantly.
Or semanticly? Ah, whatever...

Andrew Fedoniouk.
http://terrainformatica.com