Re: [whatwg] href on any element

[Andrew Fedoniouk]

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

To: "Andrew Fedoniouk" <[EMAIL PROTECTED]>
Cc: "Ian Hickson" <[EMAIL PROTECTED]>; "Anne van Kesteren" 
<[EMAIL PROTECTED]>; "WHATWG" <[EMAIL PROTECTED]>

Sent: Monday, August 28, 2006 11:05 PM
Subject: Re: [whatwg] href on any element



Andrew Fedoniouk wrote:

Ian Hickson wrote:

  
   ...
   ...
  


If we will change model of A from

to something else then it will create implications for parser.


What implications?  Changing the formal content model of an element 
doesn't change the way a parser needs to work.  Ian's example above is 
very similar to some real world examples I've seen and browser's already 
handle it just fine.


These are non-conformant browsers :)
A simply cannot have content other than inline constructions.
What UA should do in this case is not specified. Using this
is as bad as violation of following:

"The P element represents a paragraph. It cannot
contain block-level elements (including P itself)."

We all can see that browsers that just ignore this rule. And where are we
now?



The DOM looks like this:

A
+-H2
+ P



And what is semantical meaning of that? Some hyperlinked section?

If yes then let it be just :


 ...
 ...



Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] href on any element

[Lachlan Hunt]

Andrew Fedoniouk wrote:

Ian Hickson wrote:

  
   ...
   ...
  


If we will change model of A from

to something else then it will create implications for parser.


What implications?  Changing the formal content model of an element 
doesn't change the way a parser needs to work.  Ian's example above is 
very similar to some real world examples I've seen and browser's already 
handle it just fine.


The DOM looks like this:

A
+-H2
+ P

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

Re: [whatwg] href on any element

[Andrew Fedoniouk]

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

To: "Anne van Kesteren" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>
Sent: Monday, August 28, 2006 5:30 PM
Subject: Re: [whatwg] href on any element



On Mon, 28 Aug 2006, Anne van Kesteren wrote:


On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt 
<[EMAIL PROTECTED]>

wrote:
> > It's arguably a very minor improvement,
>
> The only benefit I'm aware of is the convenience it provides to authors 
> for
> hand coding, but that benefit is negligible when you consider the 
> abilities

> of many authoring tools these days.

Another thing that some author seem to want is to make an entire block a 
link,
including its header and footer. Currently such things are solved with 
markup

similar to:

 
  
  
 


...or the currently non-conforming:

  
   ...
   ...
  

We could make it conforming, I guess. The parser already supports it to
some extent.



Main purpose of  "href on any element" idea I beleive
is to minimize number of elements needed to show the
content. Less elements - more lightweight and better styleable pages.

Just for consistency: the A element can point to any element on the page
so why not any element could do that?

All implementations of Web Applications (sites) already have
situations when you need hyperlink to be a block rather than text
span.   or  will be pretty popular 
constructions.


If we will change model of A from

to something else then it will create implications for parser.
Ideally model of the element should be known upfront and
without need of CSS being loaded first. In this case parser
or DOM builder can create more optimal construction.
So it is better to allow all elements to have href than
to change model of A.

Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] href on any element

[Ian Hickson]

On Mon, 28 Aug 2006, Anne van Kesteren wrote:
>
> On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt <[EMAIL PROTECTED]>
> wrote:
> > > It's arguably a very minor improvement,
> > 
> > The only benefit I'm aware of is the convenience it provides to authors for
> > hand coding, but that benefit is negligible when you consider the abilities
> > of many authoring tools these days.
> 
> Another thing that some author seem to want is to make an entire block a link,
> including its header and footer. Currently such things are solved with markup
> similar to:
> 
>  
>   
>   
>  

...or the currently non-conforming:

   
...
...
   

We could make it conforming, I guess. The parser already supports it to 
some extent.

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

Re: [whatwg] Persistent storage is critically flawed.

[Ian Hickson]

On Mon, 28 Aug 2006, Shannon Baker wrote:
> > 
> > This is mentioned in the "Security and privacy" section; the third 
> > bullet point here for example suggests blocking access to "public" 
> > storage areas:
> > 
> >   http://whatwg.org/specs/web-apps/current-work/#user-tracking
> 
> I did read the suggestions and I know the authors have given these 
> issues thought. However, my concern is that the solutions are all 
> 'suggestions' rather than rules. I believe the standard should be more 
> definitive to eliminate the potential for browser inconsistencies.

The problem is that the solution is to use a list that doesn't exist yet. 
If the list existed and was firmly established and proved usable, then we 
could require its use, but since it is still being developed (by the 
people trying to implement the Storage APIs), we can't really require it.


> > Basically, for the few cases where an author doesn't control his 
> > subdomain space, he should be careful. But this goes without saying. 
> > The same requirement (that authors be responsible) applies to all Web 
> > technologies, for example CGI script authors must be careful not to 
> > allow SQL injection attacks, must check Referer headers, must ensure 
> > POST/GET requests are handled appropriately, and so forth.
> 
> As I pointed out this only gives control to the parent domain, not the 
> child without regard for the real-world political relationship between 
> the two. Also the implication here is that the 'parent' domain is more 
> trustworthy and important than the child - that it should always be able 
> to read a subdomains private user data. The spec doesn't give the 
> developer a chance to be responsible when it hands out user data to 
> anybody in the domain hierarchy without regard for whether they are a 
> single, trusted entity or not. Don't blame the programmer when the spec 
> dictates who can read and write the data with no regard for the authors 
> preferences. CGI scripts generally do not have this limitation so your 
> analogy is irrelevant.

It seems that what you are suggesting is that foo.example.com cannot trust 
example.com, because example.com could then steal data from 
foo.example.com. But there's a much simpler attack scenario for 
example.com: it can just take over foo.example.com directly. For example, 
it could insert new HTML code containing 

Re: [whatwg] Persistent storage is critically flawed.

[Martijn]

On 8/28/06, Jim Ley <[EMAIL PROTECTED]> wrote:

On 28/08/06, Shannon Baker <[EMAIL PROTECTED]> wrote:
> I accept tracking is inevitable but we
> shouldn't be making it easier either.

You have to remember that the WHAT-WG individual is a Google employee,
a company that now relies on accurate tracking of details, so don't be
surprised that any proposal makes tracking easier and harder to
circumvent.


Well, if the WHAT-WG individual wasn't a Google employee, but an
employee from Microsoft or Mozilla or Opera or any random government,
would that change the above text? I don't think so. So I don't think
that text is implying much, otherwise than there aren't very much
'neutral' organizations involved in writing specifications for the
web.


It's probably a design requirement, of course like all WHAT-WG stuff,
there is no explanation of the problems that are attempting to be
solved with any of the stuff, so it's impossible to really know.


From:
http://www.whatwg.org/specs/web-apps/current-work/#introduction2
"
The first is designed for scenarios where the user is carrying out a
single transaction, but could be carrying out multiple transactions in
different windows at the same time.

Cookies don't really handle this case well. For example, a user could
be buying plane tickets in two different windows, using the same site.
If the site used cookies to keep track of which ticket the user was
buying, then as the user clicked from page to page in both windows,
the ticket currently being purchased would "leak" from one window to
the other, potentially causing the user to buy two tickets for the
same flight without really noticing.
"

and:
"
The second storage mechanism is designed for storage that spans
multiple windows, and lasts beyond the current session. In particular,
Web applications may wish to store megabytes of user data, such as
entire user-authored documents or a user's mailbox, on the clientside
for performance reasons.

Again, cookies do not handle this case well, because they are
transmitted with every request.
"

That seem to me two use cases of  problems that are attempting to be
solved, not?

Regards,
Martijn


Jim.

Re: [whatwg] href on any element

[Anne van Kesteren]

On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt  
<[EMAIL PROTECTED]> wrote:

It's arguably a very minor improvement,


The only benefit I'm aware of is the convenience it provides to authors  
for hand coding, but that benefit is negligible when you consider the  
abilities of many authoring tools these days.


Another thing that some author seem to want is to make an entire block a  
link, including its header and footer. Currently such things are solved  
with markup similar to:


 
  
  
 

...


--
Anne van Kesteren

Re: [whatwg] href on any element

[Lachlan Hunt]

Ian Hickson wrote:
It isn't always clear what it would mean, either (consider , 
or ).


If the feature were to be added to Web Apps 2.0 (or other future spec) I 
think it would be sensible to limit it to inline, non-interactive, 
non-empty elements (e.g. abbr, em, strong, etc.) and a few other 
selected elements (e.g. li and td).  It should not apply to elements 
like col, br, hr, input, select, etc.



It's arguably a very minor improvement,


The only benefit I'm aware of is the convenience it provides to authors 
for hand coding, but that benefit is negligible when you consider the 
abilities of many authoring tools these days.


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

Re: [whatwg] Persistent storage is critically flawed.

[Jim Ley]

On 28/08/06, Shannon Baker <[EMAIL PROTECTED]> wrote:

I accept tracking is inevitable but we
shouldn't be making it easier either.


You have to remember that the WHAT-WG individual is a Google employee,
a company that now relies on accurate tracking of details, so don't be
surprised that any proposal makes tracking easier and harder to
circumvent.

It's probably a design requirement, of course like all WHAT-WG stuff,
there is no explanation of the problems that are attempting to be
solved with any of the stuff, so it's impossible to really know.

Jim.

Re: [whatwg] href on any element

[Lachlan Hunt]

Keryx webb wrote:
Shut me up and give me a link if this has been discussed before, but I 
can't find it on Google. Has there been any discussion of allowing the 
href-attribute in (almost) any element, as in XHTML 2.0?


Personally I think this is the one killer feature of XHTML 2 and I would 
soo much like it ASAP in all browsers.


What are the perceived benefits that make it such a "killer feature"?

http://www.whatwg.org/"; title="Web Hypertext Application 
Technology Working Group">WHATWG


makes perfect sense to me.


Theoretically, for XHTML, you could use XLink and write this (assuming 
the appropriate namespace is declared)


http://www.whatwg.org/";
title="Web Hypertext Application Technology Working Group">WHATWG

But my tests with Firefox showed that, even though it supports simple 
XLink links for generic XML, that doesn't work for XHTML elements.


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