Re: [whatwg] Early feedback on header association algorithm

[Henri Sivonen]

On Nov 22, 2008, at 15:50, Henri Sivonen wrote:


On Oct 29, 2008, at 19:43, Aaron Leventhal wrote:


1. On this part:
  "If there is a header cell in the table  whose corresponding |th | element has an ID that is equal to the value of id, then assign  
the first such header cell in tree order to the data cell. "
I don't want to implement a special local table only  
getElementByIdInTable. I'd rather have this reworded to something  
like
"If there is an element in the document with a corresponding ID  
(via getElementById) equal to the value of /id/, and it is a header  
cell in the current table, then assign it to the data cell."



While implementing a special lookup method is something that one  
would want to avoid, using getElementById has two problems:


1) It makes the association brittle under copy and paste. Consider a  
case where a page author creates a table with internal id references  
and then a maintainer duplicates the table and edits the contents of  
the copy table. Now the table coming later in the document order is  
inaccessible but this brokenness is unobvious to a person who isn't  
accessing the page with AT.


2) It makes the reporting of table relationships not form a coherent  
table. Consider a program that instead of allowing the user to  
traverse the table an arc at a time tries to pull all the arcs from  
the accessibility API and reconstruct the table in its own process  
space. If there are arcs between tables, the result is not a table  
structure at all.



Oops. I didn't read the text I quoted properly. Sorry. #2 was already  
dealt with.


However, wouldn't testing if the cell is in the current table already  
go a long way towards the complexity of implementing  
getElementByIdInTable?


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

Re: [whatwg] Early feedback on header association algorithm

[Henri Sivonen]

On Oct 29, 2008, at 19:43, Aaron Leventhal wrote:


1. On this part:
   "If there is a header cell in the table  whose corresponding |th | element has an ID that is equal to the value of id, then assign  
the first such header cell in tree order to the data cell. "
I don't want to implement a special local table only  
getElementByIdInTable. I'd rather have this reworded to something like
"If there is an element in the document with a corresponding ID (via  
getElementById) equal to the value of /id/, and it is a header cell  
in the current table, then assign it to the data cell."



While implementing a special lookup method is something that one would  
want to avoid, using getElementById has two problems:


 1) It makes the association brittle under copy and paste. Consider a  
case where a page author creates a table with internal id references  
and then a maintainer duplicates the table and edits the contents of  
the copy table. Now the table coming later in the document order is  
inaccessible but this brokenness is unobvious to a person who isn't  
accessing the page with AT.


 2) It makes the reporting of table relationships not form a coherent  
table. Consider a program that instead of allowing the user to  
traverse the table an arc at a time tries to pull all the arcs from  
the accessibility API and reconstruct the table in its own process  
space. If there are arcs between tables, the result is not a table  
structure at all.


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

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

[Martin Atkins]

Hallvord R M Steen wrote:


I've built two-three websites that use content/language negotiation
and I now consider it an architectural mistake to rely on negotiation
because the URLs no longer uniquely identify the variants I in many
scenarios need to identify. It's OK-ish to do it as a pure format
choice where the server and UA just agree on using the PNG or GIF
version for an  tag. For links *users* (and FWIW search engines,
validators and other agents) may interact with it's however a big
mistake to move away from one URL per variant of a resource. In light
of my content negotiation experiments and experience I'd say an Access
attribute in HTML would be harmful to the usability of URLs.

As a URL user (web browsing human, HTML author, linker, bookmarker,
E-mail-with-links author) I often want to be sure about what variant
of a resource I link to. To be explicit about this across scenarios
requires explicit URLs with language and type information.



Agreed. I think the assumptions underlying content negotation are 
flawed, and thus the mechanism itself is flawed and causes confusion and 
inconvenience when used in practice. The sentiment underlying this 
proposal seems to be that HTTP content negotation would work fine if 
only the pesky browsers would support it, but I think there are 
deeper-rooted problems than simply a lack of browser support.


I think a better solution is to publish the HTML version with attributed 
hyperlinks, like this:




or, if you prefer:


PDF Version


This way clients can discover the alternative representations, but the 
alternative representations are all directly addressable so you can link 
to a specific representation. This approach is used in practice 
successfully today to make available Atom representations of HTML pages 
across the web. Atom feeds are arguably the best example of a successful 
 completely-RESTful API that we have today, so this approach is proven 
to work.


In future, once IETF has finished specifying this, it may also be 
possible to do this in the HTTP response headers for non-HTML resources:


Link: ; rel="alternate", type="application/pdf"
(or something similar)

...and some other document formats such as Atom already provide 
equivalent linking constructs that you can use today.