Re: [whatwg] Lists, /, and

[dolphinling]

Michel Fortin wrote:
(Note that everything applying to normal lists in this message could 
also apply to definition lists and tables.)


The ongoing thread about a global href attribute versus a block-level 
 element made me think of a similar situation concerning  and 
. How can we markup removed or inserted list items? Here's a 
general idea:



Some list item
Another list item


But this is invalid. According to the spec the content model for  is 
"zero or more  elements".


Changing this to allow the above markup has consequences on the DOM: for 
instance we could no longer iterate on the content of a list element and 
expect to catch all of its list items. 


What's more, it's not backwards compatible. I would *love* it if it were 
(especially because then fieldset could also go there, and repetition template 
attributes wouldn't have to apply to all elements), but current UAs turn 
text into text.


I suppose it could be made valid in XML and left explicitly undefined in HTML 
with a big red flashing warning to authors not to use it as it'll probably 
change in the future, and then in 5 years or so it'll be possible to change 
it... But that would be icky. And that assumes there's not already legacy 
content that uses it. :(


To avoid the problem  and 
 could be made global attributes as some have suggested for href.


That would fail when you just wanted to remove a few words from a paragraph. And 
having both an element and an attribute would be confusing and, again, icky.


I'm not advocating any solution right now, but I think the spec should 
be either changed to allow the above, or to add global attributes, or be 
clarified to explicitly disallow  and  surrounding list items. 
Also, if links are to become applicable to block-level elements, I 
suggest it follows the same model.


--
dolphinling

[whatwg] Fw: Fw: Lists, /, and

[Andrew Fedoniouk]

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

To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2006 9:18 PM
Subject: Re: [whatwg] Fw: Lists, /, and 


On Wed, 30 Aug 2006 10:57:51 +0700, Andrew Fedoniouk 
<[EMAIL PROTECTED]> wrote:


Probably, lists should implement a special DOM interface which allows 
to

iterate over the list items. Tables have such an interface.



Why not to implement just one simple function:

  function foo(element) { ... }
 ...
 someListElement.select( "li", foo);
 -or-
 someListElement.select( "li:not(li li)", foo);

  instead of multiplying that interfaces?


This is guessing. Right now, it took you two attempts to construct a 
selector which doesn't match too many or too little nodes. Note that 
rules may change in the future. For example, there has been a proposal to 
allow OL and UL as direct descendants of other OL or UL -- if this is 
accepted, you'll need to update your selectors once again, making them 
still more complex.


Agreed in general, "I wish you to live in an era of changes" is pretty old
Chinese damnation.
But it is at least not worse than difference in DOM interface
implementations in different UAs.

Less number of interfaces - stronger hope that they will be implemented
uniformely.



On the other hand, the list can be required to "know" what its items are.



I didn't get this one, sorry.

Andrew Fedoniouk.
http://terrainformatica.com



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

Re: [whatwg] Lists, /, and

[Alexey Feldgendler]

On Wed, 30 Aug 2006 10:40:46 +0700, Andrew Fedoniouk  
<[EMAIL PROTECTED]> wrote:




   Some list item
   Another list item



Same old story about accessibility. Classes mean nothing unless styled,  
and they are usually styled only for the particular media the author is  
targetting. What should a voice UA do about these classes, for example?  
With  and , it could apply some default styling in absence of  
applicable author-specified styling, but with classes this information is  
inaccessible for a blind user.



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

Re: [whatwg] Fw: Lists, /, and

[Alexey Feldgendler]

On Wed, 30 Aug 2006 10:57:51 +0700, Andrew Fedoniouk <[EMAIL PROTECTED]> wrote:

>>> Probably, lists should implement a special DOM interface which allows to
>>> iterate over the list items. Tables have such an interface.

> Why not to implement just one simple function:
>
>   function foo(element) { ... }
>  ...
>  someListElement.select( "li", foo);
>  -or-
>  someListElement.select( "li:not(li li)", foo);
>
>   instead of multiplying that interfaces?

This is guessing. Right now, it took you two attempts to construct a selector 
which doesn't match too many or too little nodes. Note that rules may change in 
the future. For example, there has been a proposal to allow OL and UL as direct 
descendants of other OL or UL -- if this is accepted, you'll need to update 
your selectors once again, making them still more complex.

On the other hand, the list can be required to "know" what its items are.


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

[whatwg] Fw: Lists, /, and

[Andrew Fedoniouk]

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

To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2006 7:47 PM
Subject: Re: [whatwg] Lists, /, and 


On Wed, 30 Aug 2006 01:09:26 +0700, Michel Fortin 
<[EMAIL PROTECTED]> wrote:



 
 Some list item
 Another list item
 

Changing this to allow the above markup has consequences on the DOM:
for instance we could no longer iterate on the content of a list
element and expect to catch all of its list items.


Probably, lists should implement a special DOM interface which allows to 
iterate over the list items. Tables have such an interface.






Why not to implement just one simple function:

 function foo(element) { ... }
...
someListElement.select( "li", foo);
-or-
someListElement.select( "li:not(li li)", foo);

 instead of multiplying that interfaces?

Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] Lists, /, and

[Michel Fortin]

Le 29 août 2006 à 23:00, Lachlan Hunt a écrit :


Michel Fortin wrote:
How can we markup removed or inserted list items? Here's a general  
idea:


Some list item
Another list item



This can be solved by putting the ins and del elements as the only  
child nodes of the li elements instead.



  Some list item
  Another list item



The meaning of your markup is that you inserted and deleted some text  
within each list item, not that you added or deleted a list item like  
in mine. Semantically there is a difference, subtle maybe but still  
there.


Also, while your markup gives the same visual rendering while using  
the default browser stylesheet (which underlines  and  
overstrikes ), the result will be completely different if you  
want to hide the inserted or deleted parts. Using this CSS rule:


del { display: none }

you'll see a one-item list for my markup, while for your markup  
you'll see a second, empty list item.



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

Re: [whatwg] Lists, /, and

[Andrew Fedoniouk]

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

To: "Michel Fortin" <[EMAIL PROTECTED]>
Cc: "whatwg List" <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2006 8:00 PM
Subject: Re: [whatwg] Lists, /, and 



Michel Fortin wrote:
How can we markup removed or inserted list items? Here's a 
general idea:



Some list item
Another list item



This can be solved by putting the ins and del elements as the only child 
nodes of the li elements instead.



  Some list item
  Another list item




Lets forget about  or  as anyway this is better


  Some list item
  Another list item


Andrew Fedoniouk.
http://terrainformatica.com

Re: [whatwg] Lists, /, and

[Lachlan Hunt]

Michel Fortin wrote:
How can we markup removed or inserted list items? Here's a 
general idea:



Some list item
Another list item



This can be solved by putting the ins and del elements as the only child 
nodes of the li elements instead.



  Some list item
  Another list item


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

Re: [whatwg] Lists, /, and

[Alexey Feldgendler]

On Wed, 30 Aug 2006 01:09:26 +0700, Michel Fortin <[EMAIL PROTECTED]> wrote:

>  
>  Some list item
>  Another list item
>  
>
> Changing this to allow the above markup has consequences on the DOM:
> for instance we could no longer iterate on the content of a list
> element and expect to catch all of its list items.

Probably, lists should implement a special DOM interface which allows to 
iterate over the list items. Tables have such an interface.


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

Re: [whatwg] href on any element

[Kornel Lesinski]

On Tue, 29 Aug 2006 22:55:01 +0100, Matthew Raymond  
<[EMAIL PROTECTED]> wrote:


Having data table representing list of items where large clickable area  
is useful - i.e. inbox in a webmail, list of contacts, forum threads  
listing, etc.


I've ran into this problem many times and seen many questions about this
on forums/usenet.

My current solution is:



   This can be accomplished by having  elements in each individual
cell...


Ofcourse it can, but it bloats code a lot. You have to add several  
redundant links, add tabindex=-1 to avoid breaking keyboard navigation,  
move all table and cell styles to anchors, and if cells contain block  
elements you have to bloat your code even more.



Another situation where I wanted href on any element was advertisement:


My product is:

Cool
Great
And soo semantic




   People don't typically don't initiate a purchase in a user interface
by clicking on the product description.


Make it href="/info" then. Sometimes it doesn't make sense to have  
separate page for each listed detail.



Ofcourse you can live without href on every element if you apply a bit of  
scripting and CSS tricks, but the same thing can be said about almost  
every thing in WHATWG specifications.



It can have some backwards-compatibility. AFAIK XHTML/2 allows nested  
anchors, so I'd use it like this:


anchorno anchorno  
anchorno anchor


With some scripting (see first code in this post) this could work in  
current browsers and had fallback for bots and non-JS agents.


--
regards, Kornel Lesiński

Re: [whatwg] href on any element

[Matthew Raymond]

Kornel Lesinski wrote:
> On Tue, 29 Aug 2006 17:02:22 +0100, Francisco Monteiro  
> Having data table representing list of items where large clickable area is  
> useful - i.e. inbox in a webmail, list of contacts, forum threads listing,  
> etc.
> 
> I've ran into this problem many times and seen many questions about this  
> on forums/usenet.
> 
> My current solution is:
> 

   This can be accomplished by having  elements in each individual
cell...

| 
|   Content for Cell 1
|   Content for Cell 2
|   Content for Cell 3
| 

   ...where you just style the  element to be a block that takes up
the entire cell. It's not as convenient for hand-coded pages, but I
don't see a lot of use cases where you would need this for hand-coded
pages anyways.

   Now, it does make cell borders and padding a bit sticky, which is
something to consider, but that can be largely circumvented by some
clever styling. Furthermore, it represents only a small amount of the
click area that's unlikely to be clicked in the first place.

> Another situation where I wanted href on any element was advertisement:
> 
> 
> My product is:
> 
> Cool
> Great
> And soo semantic
> 
> 

   People don't typically don't initiate a purchase in a user interface
by clicking on the product description. For instance, they may simply be
clicking on the individual list items as they're reading them. (In fact,
this was an argument used against supporting label focus passing for all
types of  elements.) Simply put, what you're suggesting above is
bad UI design.

[whatwg] return lowercase hex values for fillStyle and strokeStyle

[Anne van Kesteren]

Instead of returning an uppercase six digit hex value I suggest returning  
a lowercase value for compatibility with what UAs (including IE) currently  
do for CSS already and what Mozilla already does for .



--
Anne van Kesteren

Re: [whatwg] Lists, /, and

[James Graham]

Michel Fortin wrote:
(Note that everything applying to normal lists in this message could 
also apply to definition lists and tables.)


The ongoing thread about a global href attribute versus a block-level 
 element made me think of a similar situation concerning  and 
. How can we markup removed or inserted list items? Here's a 
general idea:



Some list item
Another list item


But this is invalid. According to the spec the content model for  is 
"zero or more  elements".




As a more basic question, how does anyone actually use the / elements? 
In their current form they are too basic to do worthwhile revision control and 
specifying a generic solution that will meet all needs seems challenging. I also 
know they can't be that widely used since Hixie's survey [1] says:


 "Some of the more obscure cases of non-standard tags we found include a series 
of tags with the st1: prefix, such as , and , 
, , which we are told come from Microsoft Office 
("smarttags"). Those four tags are used more often than the ins and del elements 
from HTML4" [2]


Clearly there are some situations in which basic revision control would be 
useful but, even then, I'm not sure the revision semantics have value beyond the 
boundary of the particular environment in which the document is being edited - 
by this I mean that an aural UA, for example, could not easily make use of an 
 element in an arbitrary document, nor could the googlebot (I suppose one 
could argue more strongly for the  element). On the other hand an editing 
application, with support for revision control could easily invent some solution 
using e.g. a combination of custom classes. This will have the advantage that 
the application can represent as much or as little information as it requires 
(allowing for e.g. multi-level revision histories and extra metadata about the 
change) and the disadvantage only that the semantics are not recognised outside 
the application.


[1] http://code.google.com/webstats/index.html
[2] http://code.google.com/webstats/2005-12/editors.html

--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] proposed canvas 2d API additions

[Ian Hickson]

On Tue, 29 Aug 2006, Anne van Kesteren wrote:
> On Fri, 19 May 2006 17:34:04 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > > One other problem I had with it was that the colors are restricted to 8
> > > bit. That may potentially lead to data loss but I guess it's not a major
> > > concern yet.
> > 
> > This is already the case in other aspects of the API, I think.
> 
> As you pointed out some to me, not for percentage rgb color values.

I don't recall what this thread was about. Was there a change you wanted 
made to the spec?

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

Re: [whatwg] href on any element

[Kornel Lesinski]

On Tue, 29 Aug 2006 17:02:22 +0100, Francisco Monteiro  
<[EMAIL PROTECTED]> wrote:



What practical use has this for Mr Joe Public?

Give me a really useful example in very simple wording!


Having data table representing list of items where large clickable area is  
useful - i.e. inbox in a webmail, list of contacts, forum threads listing,  
etc.


I've ran into this problem many times and seen many questions about this  
on forums/usenet.


My current solution is:


Another situation where I wanted href on any element was advertisement:


My product is:

Cool
Great
And soo semantic



--
regards, Kornel Lesiński

[whatwg] Lists, /, and

[Michel Fortin]

(Note that everything applying to normal lists in this message could  
also apply to definition lists and tables.)


The ongoing thread about a global href attribute versus a block-level  
 element made me think of a similar situation concerning  and  
. How can we markup removed or inserted list items? Here's a  
general idea:



Some list item
Another list item


But this is invalid. According to the spec the content model for   
is "zero or more  elements".


Changing this to allow the above markup has consequences on the DOM:  
for instance we could no longer iterate on the content of a list  
element and expect to catch all of its list items. To avoid the  
problem  and  could be made global attributes as some have  
suggested for href.


I'm not advocating any solution right now, but I think the spec  
should be either changed to allow the above, or to add global  
attributes, or be clarified to explicitly disallow  and   
surrounding list items. Also, if links are to become applicable to  
block-level elements, I suggest it follows the same model.



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

Re: [whatwg] proposed canvas 2d API additions

[Anne van Kesteren]

On Fri, 19 May 2006 17:34:04 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:

One other problem I had with it was that the colors are restricted to 8
bit. That may potentially lead to data loss but I guess it's not a major
concern yet.


This is already the case in other aspects of the API, I think.


As you pointed out some to me, not for percentage rgb color values.


--
Anne van Kesteren

Re: [whatwg] href on any element

[Francisco Monteiro]

 
What practical use has this for Mr Joe Public?

Give me a really useful example in very simple wording!

Francisco
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of dolphinling
Sent: 29 August 2006 16:46
To: WHAT WG List
Subject: Re: [whatwg] href on any element

Lachlan Hunt wrote:
> Andrew Fedoniouk wrote:
>> If yes then let it be just :
>>
>> 
>>  ...
>>  ...
>> 
> 
> But that isn't backwards compatible.

data:text/html,link to
googleplain text

Neither is  around table cells or list items.

Personally, I like the semantics of href on any element. "This element is a
link" seems cleaner than "Here is a link element that surrounds some other
element or text content". Assuming no one does find a backwards-compatible
way to link any element, I'd prefer going forwards with href applying to
everything.

(Note that I haven't thought about it much, though, and I do have a vague
hazy memory of not liking something about the way XHTML 2 is doing it. I
would definitely want more thought put into it than I have.)

--
dolphinling



smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] href on any element

[dolphinling]

Lachlan Hunt wrote:

Andrew Fedoniouk wrote:

If yes then let it be just :


 ...
 ...



But that isn't backwards compatible.


data:text/html,link to 
googleplain text


Neither is  around table cells or list items.

Personally, I like the semantics of href on any element. "This element is a 
link" seems cleaner than "Here is a link element that surrounds some other 
element or text content". Assuming no one does find a backwards-compatible way 
to link any element, I'd prefer going forwards with href applying to everything.


(Note that I haven't thought about it much, though, and I do have a vague hazy 
memory of not liking something about the way XHTML 2 is doing it. I would 
definitely want more thought put into it than I have.)


--
dolphinling

Re: [whatwg] Persistent storage is critically flawed.

[Shannon Baker]

Ian Hickson said (among other things):
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] href on any element

[Ric Hardacre]

Ian Hickson wrote:
> 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.
> 

I've run up against this before, the only way you can get it to conform
is by repeating the anchor:

Foo
Bar

or by the previous, non semantic use of spans. All that is required is
to allow the anchor to be used around block level elements. The anchor
could be treated as a non element, where any plain text within is by
default treated as inline. after all it's fine to surround some
inline-replaced elements such as images with A but not others, such as
inputs (though why anyone would want to do the latter is open to debate.)

this could also lead to clearer use of named anchors too, if they were
allowed to

1. surround the entire region they refer to
2. nest


Appendix 1
References
1. ... ...
...


Question is, is this backwards compatible? do existing UAs treat this as
 a series of  tag pairs or does the nesting break it? If a
named-anchor surrounded it's region it would also allow screen readers
(for example) to very easily jump to a footnote and read it without
having to guess where to stop and return to the main text.

Ric Hardacre
http://www.cyclomedia.co.uk/

[whatwg] Table integrity and conformance

[Henri Sivonen]

Should one expect HTML table row/column integrity to become an HTML5  
conformance requirement?


That is, will these tables be non-conforming:










?

(This is something static document authors probably would prefer to  
have flagged, and for dynamic document authors it isn't a  
particularly good idea to leave the DOM in an incoherent state for  
prolonged times.)


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

Re: [whatwg] href on any element

[Lachlan Hunt]

Andrew Fedoniouk wrote:

Lachlan Hunt wrote:

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 :)


No, in this case, they're just handling the non-conformant content in 
the most sane way, which I believe (in this case) is correct handling 
according to traditional SGML rules.


See the Parse Tree produced by the validator for that construct
(ignore the 2 expected validation errors):
http://validator.w3.org/check?uri=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%253C%21DOCTYPE%2520a%2520PUBLIC%2520%2522-%252F%252FW3C%252F%252FDTD%2520HTML%25204.01%252F%252FEN%2522%253E%250D%250A%253Ca%2520href%253D%2522%2523%2522%253E%250D%250A%2520%2520%253Ch2%253E...%253C%252Fh2%253E%250D%250A%2520%2520%253Cp%253E...%253C%252Fp%253E%250D%250A%253C%252Fa%253E%2520&charset=%28detect+automatically%29&doctype=Inline&sp=1


A simply cannot have content other than inline constructions.


According to the formal content model, yes, but when a browser 
encounters a real world document has that construct, what do you think 
the browser should do with it?



What UA should do in this case is not specified. Using this
is as bad as violation of following:


See section 8 of the Web Apps 1.0 spec.
http://www.whatwg.org/specs/web-apps/current-work/#parsing


The DOM looks like this:

A
+-H2
+ P


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


The A element is just defined as a hyperlink.  Whether or not it's a 
section is irrelevant.



If yes then let it be just :


 ...
 ...



But that isn't backwards compatible.

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