Re: [whatwg] Fw: Lists, ins/del, and a
Andrew Fedoniouk wrote: someListElement.select( li:not(li li), foo); That selector won't work anyway, because (according to the Selectors spec) :not() can only contain a single simple selector. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Andrew Fedoniouk wrote: Lets forget about ins or del as anyway this is better ol li class=new inversion=Some list item/li li class=removed inversion=Another list item/li /ol I don't know what the inversion attribute is supposed to mean, but the class attribute is semantically meaningless. However, we could introduce the edit and datetime attributes from the XHTML 2.0 draft's Edit Attributes Module [1]. Then we could just define that ins and del are semantically equivalent to div edit=inserted and div edit=deleted (or span, when used as inline elements), respectively. That way, we could use this: ul li edit=insertedSome list item/li li edit=deletedAnother list item/li li edit=changedModified list item/li li edit=movedMoved list item/li /ul [1] http://www.w3.org/TR/xhtml2/mod-edit.html -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Fw: Lists, ins/del, and a
- Original Message - From: Lachlan Hunt [EMAIL PROTECTED] To: Andrew Fedoniouk [EMAIL PROTECTED] Cc: whatwg List [EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 12:07 AM Subject: Re: [whatwg] Fw: Lists, ins/del, and a Andrew Fedoniouk wrote: someListElement.select( li:not(li li), foo); That selector won't work anyway, because (according to the Selectors spec) :not() can only contain a single simple selector. Discussed this already last week or so on www-styles list. Andrew Fedoniouk. http://terrainfromatica.com -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Michel Fortin wrote: 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: ul insliSome list item/li/ins delliAnother list item/li/del /ul This can be solved by putting the ins and del elements as the only child nodes of the li elements instead. ul liinsSome list item/ins/li lidelAnother list item/del/li /ul 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. Another related thought we could discuss for revision control using ins and del is that they could do with a couple of attributes, a datetime and an author: pOn a dull and dreary afternoon ins datetime=2006-27-08 12:34:56 author=Ric HardacreI added this text while/ins the rain poured down/p Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Lists, ins/del, and a
On Wed, 30 Aug 2006 05:51:39 +0200, Michel Fortin
[EMAIL PROTECTED] wrote:
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.
That depends on the definition.
Also, while your markup gives the same visual rendering while using the
default browser stylesheet (which underlines ins and overstrikes
del), 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.
That could be seen as a limitation of the styling language. It has been
repeated many times on this list that styling should not be taken into
account when designing markup.
(As for my myself, I only partially agree with that sentiment.)
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Lists, ins/del, and a
Ric Hardacre wrote: Another related thought we could discuss for revision control using ins and del is that they could do with a couple of attributes, a datetime http://www.w3.org/TR/html401/struct/text.html#adef-datetime and an author: pOn a dull and dreary afternoon ins datetime=2006-27-08 12:34:56 author=Ric HardacreI added this text while/ins the rain poured down/p Maybe. What's the use case and what benefit does it provide? Would a name be a suitable value, or would a URI pointing to more info about the author be better (e.g. linking to the author's profile or homepage). Would the use cases be better handled using CVS or SVN on the back end? Would any user need to know which author edited something? I could be wrong, but I believe author information is recorded by office applications (e.g. Word, OpenOffice) when revision control is enabled; but, again, would it be useful to have it saved in HTML? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
On Wed, 30 Aug 2006 09:16:54 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: I don't know what the inversion attribute is supposed to mean, but the class attribute is semantically meaningless. However, we could introduce the edit and datetime attributes from the XHTML 2.0 draft's Edit Attributes Module [1]. I've personally proposed that as well, at least once. The problem, similar to introducing href= everywhere is that it's not backwards compatible. However, as opposed to a href=, del and ins are not often used and don't provide important functionality (the interaction most users have with them is their visual appearance). [1] http://www.w3.org/TR/xhtml2/mod-edit.html -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Lists, ins/del, and a
Anne van Kesteren wrote:
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.
That could be seen as a limitation of the styling language. It has been
repeated many times on this list that styling should not be taken into
account when designing markup.
But you do have to design the markup language in a way that satisfies
the use cases. In this case, it clearly doesn't satisfy at least one of
them.
The edit attribute would meet this one, as you could use:
li[edit=deleted] { display: none; }
It's even somewhat backwards compatible with current browsers.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] href on any element
Kornel Lesinski wrote:
My current solution is:
tr onclick=this.getElementsByTagName('a')[0].click()
This can be accomplished by having a elements in each individual
cell...
Of course 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.
It didn't occur to me until recently, but the behavior you originally
described isn't desirable from an interface design standpoint. How is a
person supposed to highlight and copy specific information within an
given cell in the row? Furthermore, if two cells next to each other have
the same hyperlink, but the row has a different hyperlink, it's not
entirely clear what happens if you click the space between the two
cells. With hyperlinks for each cell, or even each block, the worst that
happens is that the hyperlink doesn't get clicked, whereas with a
potential |href| attribute would have to handle nested hyperlinks and
multi-block hyperlinks that imply a grouping of elements without
necessarily encouraging a parent element with the semantics necessary to
identify the nature of that grouping.
That said, I'd also like to point out that most of your arguments for
|href| fall into the category of convenience rather than necessity.
Another situation where I wanted href on any element was advertisement:
div href=/buy
pMy product is:/p
ul
liCool/li
liGreat/li
liAnd soo semantic/li
/ul
/div
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.
The fundamental problems with the UI design don't really go away when
you change the purpose of the hyperlink. You still have the problem that
people don't necessarily expect that clicking anywhere on an entire
list, or even the opening paragraph, would lead to another page. It also
has issues with interacting the individual elements of the list, just
like you would with cells in a row.
Of course 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.
The difference here is that the potential for poor interface design
goes up significantly. In fact, |href| could be used as a means of
preventing the user from interacting with an element and its descendants.
It can have some backwards-compatibility. AFAIK XHTML/2 allows nested
anchors, so I'd use it like this:
tr href=..tda href=..anchor/a/tdtdno anchor/tdtdno
anchor/tdtdno anchor/td/tr
Problem is that you essentially have to do all the stuff you
complained about earlier to get full backwards compatibility...
With some scripting (see first code in this post) this could work in
current browsers and had fallback for bots and non-JS agents.
With some scripting, you could just use the scripting trick you
showed in an earlier example, so what's the point? Just use that little
bit of scripting:
| tr onclick=this.getElementsByTagName('a')[0].click()
Re: [whatwg] Lists, ins/del, and a
Le 30 août 2006 à 2:49, dolphinling a écrit : 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 ulinslitext/li/ins/ul into ins/insullitext/li/ul. Safari, Mozilla and Opera all seems to build the DOM tree as it should, wherever I try ins, del, or a, or even fieldset. Are you talking solely about Internet Explorer for Windows (which I haven't tested) ? While it works fine with ul I note that it doesn't within table, showing the same behaviour as in your ul example above. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Lists, ins/del, and a
- Original Message -
From: Anne van Kesteren [EMAIL PROTECTED]
To: WHATWG [EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 1:35 AM
Subject: Re: [whatwg] Lists, ins/del, and a
| On Wed, 30 Aug 2006 09:16:54 +0200, Lachlan Hunt
| [EMAIL PROTECTED] wrote:
| I don't know what the inversion attribute is supposed to mean, but the
| class attribute is semantically meaningless. However, we could
| introduce the edit and datetime attributes from the XHTML 2.0 draft's
| Edit Attributes Module [1].
|
| I've personally proposed that as well, at least once. The problem, similar
| to introducing href= everywhere is that it's not backwards compatible.
| However, as opposed to a href=, del and ins are not often used and
| don't provide important functionality (the interaction most users have
| with them is their visual appearance).
|
Anne, seems like I don't understand what backward compatible [1]
means in this context. Could you explain what you mean here?
Outdated UA will not interpret li href=... but will do a href=...
Up-to-date UA will understand both.
Looks as backward compatible solution to me.
Andrew Fedoniouk.
http://terrainformatica.com
OT little bit:
in h-smile engine (htmlayout,etc) hyperlink implemented as a behavior:hyperlink
Intrinsically [2] it applied to a[href] elements only but can be assigned
to any DOM element as *[href] { behavior:hyperlink; } using CSS.
[1] http://en.wikipedia.org/wiki/Backward_compatibility
[2] http://www.terrainformatica.com/htmlayout/master_ss_css.php
|
| [1] http://www.w3.org/TR/xhtml2/mod-edit.html
|
|
|
| --
| Anne van Kesteren
| http://annevankesteren.nl/
| http://www.opera.com/
|
|
Re: [whatwg] Lists, ins/del, and a
Lachlan Hunt wrote: we could introduce the edit and datetime attributes from the XHTML 2.0 draft's Edit Attributes Module [1]. I just realised that the datetime attribute from the Edit module would clash with the proposed datetime attribute of the t element [1]. e.g. What would the datetime attribute mean in this? t edit=inserted datetime=2006-08-3131 Aug 2006/t It could either mean that the markup was inserted on 2006-08-31 or that the content is a date equivalent to 2006-08-31. A possible solution could be to keep edit and datetime attributes for editing and rename the datetime attribute for the t element to something else (e.g. dt) e.g. t dt=2006-08-3131 Aug 2006/t t dt=2006-08-31 edit=inserted datetime=2006-09-01T12:30Z31 Aug 2006/t The problem with that is that authors may get confused and use datetime instead of dt, or vice versa. Alternatively, we could use the title attribute instead. e.g. t title=2006-08-3131 Aug 2006/t That has the advantage of actually making the ISO date accessible to users using the existing tooltip mechansim and is similar to the current abuse of the abbr element for the datetime microformat [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/#the-t [2] http://microformats.org/wiki/datetime-design-pattern -- Lachlan Hunt http://lachy.id.au/
