<spoiler> element

[Jeremy Rand]

I have a suggestion for an element which could be included in XHTML 2.
This is a <spoiler> element.  This element would have the content of a
<spoildesc> element, and a <spoilcontent> element.  The behavior would
be that when the user agent encounters a <spoiler> element, it should
render the content of its <spoildesc>, and provide a way for the user to
activate the <spoiler>.  Once the <spoiler> is activated, the user agent
should show the content of the <spoilcontent>.

This would be useful in many situations where the user might not want to
see certain content.  Examples are:

Spoilers of the plot of a book or movie
Offensive language
Disturbing medical photos
Pornographic or otherwise not-safe-for-work content
The answer to a riddle
Content with flashing lights that could cause epileptic seizures

I'm sure there are more examples of uses for <spoiler>, but I can't
think of any more right now.

An example of its usage would be:

<p>Did you hear about the cement mixer that ran over Batman and Robin?</p>
<p><spoiler>
<spoildesc>Activate to see punchline.</spoildesc>
<spoilcontent>It created two new superheroes: Flatman and
Ribbon.</spoilcontent>
</spoiler></p>

I know <spoiler> isn't a very good name for it, since there are other
uses as well, but I can't think of a better name.  I know that <spoiler>
is implemented into a forum-hosting site's posting system (I can't
remember which site); it just displays the content of <spoiler> in
identical foreground and background colors so that you must select the
text to read it.  Also, I realize that this could be done using either
scripting or links, but I think links are inappropriate, since the
content is part of the original document.  I think scripting is
inappropriate, since this has semantic meaning, so I think it should be
a standard XHTML element.

Does this proposal sound good?

Thanks,
Jeremy Rand

PS: Norton E-mail Proxy says this message didn't send properly, so I'm
sending it again.  Apologies if anyone receives two copies.

[Alan Trick]

I only received 1 email, so don't worry.

Anyways, my reaction to this is a definate no. The point of (X)HTML is
not to describe everything that could possibly have semantics. It is to
provide a common language that everyone can use. When we add more terms
(elements, attributes, etc) we make the language more difficult - both
for the authours (the webmasters who have to know HTML) and the readers
(the browsers and bots who have to implement the stuff). In my oppinion
this is not a generic enough element to be useful.

Try using a deffinition list with the class of 'spoiler', and then style
it CSS and add javascript that will do what you want.

Alan Trick

On Tue, 2005-12-06 at 17:48 -0600, Jeremy Rand wrote:

> I have a suggestion for an element which could be included in XHTML 2.
> This is a <spoiler> element.  This element would have the content of a
> <spoildesc> element, and a <spoilcontent> element.  The behavior would
> be that when the user agent encounters a <spoiler> element, it should
> render the content of its <spoildesc>, and provide a way for the user to
> activate the <spoiler>.  Once the <spoiler> is activated, the user agent
> should show the content of the <spoilcontent>.
>
> This would be useful in many situations where the user might not want to
> see certain content.  Examples are:
>
> Spoilers of the plot of a book or movie
> Offensive language
> Disturbing medical photos
> Pornographic or otherwise not-safe-for-work content
> The answer to a riddle
> Content with flashing lights that could cause epileptic seizures
>
> I'm sure there are more examples of uses for <spoiler>, but I can't
> think of any more right now.
>
> An example of its usage would be:
>
> <p>Did you hear about the cement mixer that ran over Batman and Robin?</p>
> <p><spoiler>
> <spoildesc>Activate to see punchline.</spoildesc>
> <spoilcontent>It created two new superheroes: Flatman and
> Ribbon.</spoilcontent>
> </spoiler></p>
>
> I know <spoiler> isn't a very good name for it, since there are other
> uses as well, but I can't think of a better name.  I know that <spoiler>
> is implemented into a forum-hosting site's posting system (I can't
> remember which site); it just displays the content of <spoiler> in
> identical foreground and background colors so that you must select the
> text to read it.  Also, I realize that this could be done using either
> scripting or links, but I think links are inappropriate, since the
> content is part of the original document.  I think scripting is
> inappropriate, since this has semantic meaning, so I think it should be
> a standard XHTML element.
>
> Does this proposal sound good?
>
> Thanks,
> Jeremy Rand
>
> PS: Norton E-mail Proxy says this message didn't send properly, so I'm
> sending it again.  Apologies if anyone receives two copies.
>
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

[Jukka K. Korpela]

On Wed, 7 Dec 2005, Alan Trick wrote:

> When we add more terms
> (elements, attributes, etc) we make the language more difficult

Undoubtedly. Trivial languages like XML (as such) are so tempting since
they leave the real problems to others.

> - both for the authours (the webmasters who have to know HTML)

You don't need to know elements that you don't have use for.

> and the readers
> (the browsers and bots who have to implement the stuff).

That's just browsers, not "readers" in general. The proposed element
would have semantics that browsers _need_ to observe. It's a bit more
complicated question whether indexing robots should observe it too.
But _users_ need not worry, except that they would need to learn _one_
mechanism to reveal the "hidden" content, instead of zillions of methods
that pages do in the absence of a general markup element.

> In my oppinion
> this is not a generic enough element to be useful.

Au contraire. As described, it is probably _too_ generic, but this
could be fixed.

> Try using a deffinition list with the class of 'spoiler', and then style
> it CSS and add javascript that will do what you want.

This is a good example where we get when we have too trivial a markup
language. We have varying (and usually poor-quality) homebrew techniques
to implement a simple thing, perhaps abusing markup (e.g., definition list
for something that is not a list of definitions), using client-side
scripting which might be switched off in browsers, and using CSS for
essential division of content to displayed and non-displayed, instead of
using CSS for its intended purposes: optional suggestions on presentation.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

[Mark Birbeck]

Hi Alan/Jeremy,

On the *semantic* side of this, the purpose of @role is to provide features
that may be an absolute necessity in one domain but completely irrelevant in
another. So rather than having to fight over them on the list all the time,
each sphere that is using XHTML 2 can add whatever they like. :)

In this case, we might have:

  <section role="x:spoiler">
    <p>The butler did it.</p>
  </section>

As to the *behaviour* side, that's a little more tricky. Work is going on to
provide a way to define the behaviour of different values of role, using
RDF. I would hope that x:spoiler could somewhere be defined as inheriting
from a role that "shows and hides itself on user activation". (This could
actually be in the document itself.)

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@...
t: [phone]
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: www-html-request@...
> [mailto:www-html-request@...] On Behalf Of Alan Trick
> Sent: 07 December 2005 09:30
> To: www-html@...
> Subject: Re: <spoiler> element
>
>
> I only received 1 email, so don't worry.
>
> Anyways, my reaction to this is a definate no. The point of
> (X)HTML is not to describe everything that could possibly
> have semantics. It is to provide a common language that
> everyone can use. When we add more terms (elements,
> attributes, etc) we make the language more difficult - both
> for the authours (the webmasters who have to know HTML) and
> the readers (the browsers and bots who have to implement the
> stuff). In my oppinion this is not a generic enough element
> to be useful.
>
> Try using a deffinition list with the class of 'spoiler', and
> then style it CSS and add javascript that will do what you want.
>
> Alan Trick
>
> On Tue, 2005-12-06 at 17:48 -0600, Jeremy Rand wrote:
> > I have a suggestion for an element which could be included
> in XHTML 2.
> > This is a <spoiler> element.  This element would have the
> content of a
> > <spoildesc> element, and a <spoilcontent> element.  The
> behavior would
> > be that when the user agent encounters a <spoiler> element,
> it should
> > render the content of its <spoildesc>, and provide a way
> for the user
> > to activate the <spoiler>.  Once the <spoiler> is
> activated, the user
> > agent should show the content of the <spoilcontent>.
> >
> > This would be useful in many situations where the user
> might not want
> > to see certain content.  Examples are:
> >
> > Spoilers of the plot of a book or movie Offensive language
> Disturbing
> > medical photos Pornographic or otherwise not-safe-for-work
> content The
> > answer to a riddle Content with flashing lights that could cause
> > epileptic seizures
> >
> > I'm sure there are more examples of uses for <spoiler>, but I can't
> > think of any more right now.
> >
> > An example of its usage would be:
> >
> > <p>Did you hear about the cement mixer that ran over Batman and
> > Robin?</p> <p><spoiler> <spoildesc>Activate to see
> > punchline.</spoildesc> <spoilcontent>It created two new
> superheroes:
> > Flatman and Ribbon.</spoilcontent> </spoiler></p>
> >
> > I know <spoiler> isn't a very good name for it, since there
> are other
> > uses as well, but I can't think of a better name.  I know that
> > <spoiler> is implemented into a forum-hosting site's
> posting system (I
> > can't remember which site); it just displays the content of
> <spoiler>
> > in identical foreground and background colors so that you
> must select
> > the text to read it.  Also, I realize that this could be done using
> > either scripting or links, but I think links are
> inappropriate, since
> > the content is part of the original document.  I think scripting is
> > inappropriate, since this has semantic meaning, so I think
> it should
> > be a standard XHTML element.
> >
> > Does this proposal sound good?
> >
> > Thanks,
> > Jeremy Rand
> >
> > PS: Norton E-mail Proxy says this message didn't send
> properly, so I'm
> > sending it again.  Apologies if anyone receives two copies.
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection
> around http://mail.yahoo.com 
>
>
>

[Jukka K. Korpela]

On Wed, 7 Dec 2005, Mark Birbeck wrote:

> On the *semantic* side of this, the purpose of @role is to provide features
> that may be an absolute necessity in one domain but completely irrelevant in
> another. So rather than having to fight over them on the list all the time,
> each sphere that is using XHTML 2 can add whatever they like. :)

It sounds like you're saying, in effect, that the role attribute is
included since it helps to avoid discussing and solving problems.

I fail to see the difference between that and saying that everyone and
each "domain" (area of application) can use extra attributes and tags
to supplement the XHTML soup. Well, there is a formal difference, and
a technical difference too.

To apply similar strategy to _elements_, we could add, say, the
<dwim> element in XHTML 2.0, with a required attribute 'means'
which contains the semantics in some formalism. Oops, we already
have <span> and <div>, and 'role' is shorter than 'means' (so let's
ignore its obscurity).

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

[Tina Holmboe]

On  7 Dec, Mark Birbeck wrote:

> On the *semantic* side of this, the purpose of @role is to provide
> features that may be an absolute necessity in one domain but
> completely irrelevant in another. So rather than having to fight over
> them on the list all the time, each sphere that is using XHTML 2 can
> add whatever they like. :)

  Yes ... the idea is an interesting one.

  Instead of agreeing on a common set of elements and their
  interpretation, the XHTML 2 specification basically provide a
  mechanism for overloading the semantics of existing elements.[*]

  Mapped to natural languages this can described by saying that, in
  English, the word "foo" means - in the same context, mind - not only
  "foo", but possibly "bar" and quite likely also "baz".

  Of course, this does make it somewhat more difficult to write
  dictionaries, but that's not a problem: we'll simply write one per
  area of expertise. It's a common enough practice out in the real
  world.

  However ... in order for a random user NN to gain access to the
  underlying semantics of documents on an XHTML 2 web, he or she will
  need a browser able to understand any, and all, of the author-extended
  language it might run across.

  This theoretical UA will, in other words, need not only understand the
  basic semantics of XHTML itself, but also any overloading a random
  author might come up with.

  The task of writing such a system feels somewhat daunting, but I am
  intrigued enough to consider starting such a project. I believe I will
  call it "Babel".



 [*]
  Feel free to step in here and tell me how wrong I am. It would cheer
  me up something beautifully.

--
 -    Tina Holmboe                    Greytower Technologies
   tina@...                http://www.greytower.net/
   [+46] 0708 557 905

[Mark Birbeck]

What on earth are you talking about?

Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@...
t: [phone]
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: www-html-request@...
> [mailto:www-html-request@...] On Behalf Of Jukka K. Korpela
> Sent: 07 December 2005 10:39
> To: www-html@...
> Subject: RE: <spoiler> element
>
>
> On Wed, 7 Dec 2005, Mark Birbeck wrote:
>
> > On the *semantic* side of this, the purpose of @role is to provide
> > features that may be an absolute necessity in one domain but
> > completely irrelevant in another. So rather than having to
> fight over
> > them on the list all the time, each sphere that is using
> XHTML 2 can
> > add whatever they like. :)
>
> It sounds like you're saying, in effect, that the role
> attribute is included since it helps to avoid discussing and
> solving problems.
>
> I fail to see the difference between that and saying that
> everyone and each "domain" (area of application) can use
> extra attributes and tags to supplement the XHTML soup. Well,
> there is a formal difference, and a technical difference too.
>
> To apply similar strategy to _elements_, we could add, say,
> the <dwim> element in XHTML 2.0, with a required attribute 'means'
> which contains the semantics in some formalism. Oops, we
> already have <span> and <div>, and 'role' is shorter than
> 'means' (so let's ignore its obscurity).
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
>

[Mark Birbeck]

Hi Tina,

>   Yes ... the idea is an interesting one.
>
>   Instead of agreeing on a common set of elements and their
>   interpretation, the XHTML 2 specification basically provide a
>   mechanism for overloading the semantics of existing elements.[*]

The XHTML 2 spec has many 'common' elements--if it didn't there would be
nothing to write about. However, these elements are fairly broad, and relate
mainly to general notions of document structure; head and body, obviously,
but also things like lists and sections, footers and side-bars. The latter
two are supported via @role.


>   Mapped to natural languages this can described by saying that, in
>   English, the word "foo" means - in the same context, mind - not only
>   "foo", but possibly "bar" and quite likely also "baz".

No, it doesn't. The parallel you need isn't within the realm of the
language, it's with the object itself. If I call my son 'Louis', he doesn't
cease to be my son. The same goes for if he *plays the role of* a 'Wise Man'
in the school nativity play.

So it's important to see semantics as operating at different layers, rather
than being monolithic. No-one has talked of 'overloading'; a <section> is
still a 'section', but it is now also a 'spoiler'. What each system does
with the information it now has, that some element is a 'spoiler' (or a
footnote, vCard, diary date, tourist location...and so on) is up to it. But
hopefully, if it does not understand 'spoiler', it can still process the
element as a 'section'.

This means that you could have:

  <section role="spoiler">
    ...
  </section>

Or:

  <ol role="spoiler">
    ...
  </ol>

And the semantics of a 'spoiler' would be untouched, as would the semantics
of 'section' and 'ol'.

>   However ... in order for a random user NN to gain access to the
>   underlying semantics of documents on an XHTML 2 web, he or she will
>   need a browser able to understand any, and all, of the
> author-extended
>   language it might run across.
>
>   This theoretical UA will, in other words, need not only
> understand the
>   basic semantics of XHTML itself, but also any overloading a random
>   author might come up with.

Well, sort of. But we can go a long way towards that with other mechanisms.
For example, as I said in my earlier email, the tricky point that Jukka's
email raises is how do we get the *behaviour* that he wants? At a semantic
level, @role="x:spoiler" is fine, and does the job. But how do we make it
show and hide, for example? The answer in this particular case, I think, is
to have a CSS property that gives us the behaviour we want, and then apply
it to any element that has @role="x:spoiler".

That way any viewer/browser could behave correctly, even if it had never
heard of 'x:spoiler'. But most importantly, it leaves it to the author and
the user (if you have personal stylesheets) to decide how x:spoilers should
behave; Scrooge may not choose to hide any x:spoilers as he browses the film
listings.


>   The task of writing such a system feels somewhat daunting, but I am
>   intrigued enough to consider starting such a project. I
> believe I will
>   call it "Babel".

We are indeed writing such a system, and one that actually uses more
powerful techniques than those I have described here. Daunting or not, it
opens up enormous possibilities. You have to admit that at the moment the
so-called Semantic Web amounts to some great presentations and slides, but
not a lot else.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@...
t: [phone]
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

[Bjoern Hoehrmann]

* Mark Birbeck wrote:
>The XHTML 2 spec has many 'common' elements--if it didn't there would be
>nothing to write about. However, these elements are fairly broad, and relate
>mainly to general notions of document structure;

Yeah, like <kbd>, <var>, <samp>, and <extension>, hardly any web site
without them!

>At a semantic level, @role="x:spoiler" is fine, and does the job.

Yeah. <!--###Spoiler###--> does, too.
--
Bj?rn H?hrmann ? mailto:bjoern@... ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: [phone] ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

[Oskar Welzl]

Jeremy,

I find it tempting to add the suggested <spoiler> to XHTML 2. I agree
that its use of "show this content only when activated by the user" is
generic enough to be handled by a XHTML element. I agree that the  CSS
+scripting solution is by far not good enough. And I have to say that
@role is not a solution at all:
It might offer a way to tell what the 'spoiler' is. But it is not a way
for an author to clearly tell a browser how to act on the element marked
@role="x:spoiler", given that scripting/CSS might not work as intended
on the UA that renders the page (custom style sheets, no scripting etc).

I have to say, though, that HTML always offered the very generic "show
this content only when activated by the user"-element:
<a href="http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2">Click
here only if you want to read which element it is.</a>

This is as generic as can be - and as specific as we can allow,
probably. It is not the sophisticated "show within the current
page"-solution you want. It does not fully cover all use cases:
Disturbing medical photos within a scientific text should probably be
shown right within the paragraph that describes them, not on a separate
page. But that would be <show-disturbing-medical-pictures>, not just
<spoiler> ;-)

Regards,
Oskar



Am Dienstag, den 06.12.2005, 17:48 -0600 schrieb Jeremy Rand:

> I have a suggestion for an element which could be included in XHTML 2.
> This is a <spoiler> element.  This element would have the content of a
> <spoildesc> element, and a <spoilcontent> element.  The behavior would
> be that when the user agent encounters a <spoiler> element, it should
> render the content of its <spoildesc>, and provide a way for the user to
> activate the <spoiler>.  Once the <spoiler> is activated, the user agent
> should show the content of the <spoilcontent>.
>
> This would be useful in many situations where the user might not want to
> see certain content.  Examples are:
>
> Spoilers of the plot of a book or movie
> Offensive language
> Disturbing medical photos
> Pornographic or otherwise not-safe-for-work content
> The answer to a riddle
> Content with flashing lights that could cause epileptic seizures
>
> I'm sure there are more examples of uses for <spoiler>, but I can't
> think of any more right now.
>
> An example of its usage would be:
>
> <p>Did you hear about the cement mixer that ran over Batman and Robin?</p>
> <p><spoiler>
> <spoildesc>Activate to see punchline.</spoildesc>
> <spoilcontent>It created two new superheroes: Flatman and
> Ribbon.</spoilcontent>
> </spoiler></p>
>
> I know <spoiler> isn't a very good name for it, since there are other
> uses as well, but I can't think of a better name.  I know that <spoiler>
> is implemented into a forum-hosting site's posting system (I can't
> remember which site); it just displays the content of <spoiler> in
> identical foreground and background colors so that you must select the
> text to read it.  Also, I realize that this could be done using either
> scripting or links, but I think links are inappropriate, since the
> content is part of the original document.  I think scripting is
> inappropriate, since this has semantic meaning, so I think it should be
> a standard XHTML element.
>
> Does this proposal sound good?
>
> Thanks,
> Jeremy Rand
>
> PS: Norton E-mail Proxy says this message didn't send properly, so I'm
> sending it again.  Apologies if anyone receives two copies.
>
>
>

[Daniel Glazman]

Mark Birbeck wrote:

> In this case, we might have:
>
>   <section role="x:spoiler">
>     <p>The butler did it.</p>
>   </section>

OMG...

With all due respect Mark, this _is_ the kind of stuff that makes me think
XHTML 2 is on a totally wrong track.

</Daniel>

[Devin Bayer]

Oskar Welzl wrote:

>
> I have to say, though, that HTML always offered the very generic "show
> this content only when activated by the user"-element:
> <a href="http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2">Click
> here only if you want to read which element it is.</a>
>
> This is as generic as can be - and as specific as we can allow,
> probably. It is not the sophisticated "show within the current
> page"-solution you want. It does not fully cover all use cases:
> Disturbing medical photos within a scientific text should probably be
> shown right within the paragraph that describes them, not on a separate
> page. But that would be <show-disturbing-medical-pictures>, not just
> <spoiler> ;-)

So, basically, the <spoiler> element is already provided with the XLink
language and the show="embed" attribute.  This is esentialy the equivalent
of <a target="inline">.  See:

http://www.w3.org/TR/2001/REC-xlink-20010627/#show-att

This is much more generic then <spoiler>, which for the most useful
applications is incorrectly named.

-- Devin Bayer

[Oskar Welzl]

Shall we try one more "XLink in XHTML 2.0"?
Count my vote. - But I'm afraid I'm too late. Again. :-(

Am Mittwoch, den 07.12.2005, 08:41 -0800 schrieb Devin Bayer:

> Oskar Welzl wrote:
> >
> > I have to say, though, that HTML always offered the very generic "show
> > this content only when activated by the user"-element:
> > <a href="http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2">Click
> > here only if you want to read which element it is.</a>
> >
> > This is as generic as can be - and as specific as we can allow,
> > probably. It is not the sophisticated "show within the current
> > page"-solution you want. It does not fully cover all use cases:
> > Disturbing medical photos within a scientific text should probably be
> > shown right within the paragraph that describes them, not on a separate
> > page. But that would be <show-disturbing-medical-pictures>, not just
> > <spoiler> ;-)
>
> So, basically, the <spoiler> element is already provided with the XLink
> language and the show="embed" attribute.  This is esentialy the equivalent
> of <a target="inline">.  See:
>
> http://www.w3.org/TR/2001/REC-xlink-20010627/#show-att
>
> This is much more generic then <spoiler>, which for the most useful
> applications is incorrectly named.
>
> -- Devin Bayer
>

[Kelly Miller]

XLink as it is right now would be very bad for XHTML.  I seriously doubt
page authors will want to have to declare a simple link EVERY SINGLE
TIME they want to have a link.

Oskar Welzl wrote:

>Shall we try one more "XLink in XHTML 2.0"?
>Count my vote. - But I'm afraid I'm too late. Again. :-(
>  
>
--
http://www.mozilla.org/products/firefox/ - Get Firefox!
http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox!

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

[Sunil-4]

Hi Jeremy,

its an interesting question about how extensible HTML should be
and whether it is appropriate to have non generic elements such
as <spoiler> defined in the standards. I'm not so sure that this
is a good idea as it then might be equally valid to have other non
generic tags defined in the standards as Oskar indicated.

Another way of looking at this perhaps is to ask whether XHTML 2
provides a generic mechanism by which custom elements can be defined.
I haven't absorbed all the XHTML documents but at first glance it
sounds like XHTMLMOD may be worth reading..

http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/introduction.htm
l#s_intro
        "The modularization of XHTML refers to the task of specifying
        well-defined sets of XHTML elements that can be combined and
        extended by document authors, document type architects, other
        XML standards specifications, and application and product
        designers to make it economically feasible for content developers
        to deliver content on a greater number and diversity of platforms."

Cheers

Sunil
--
release the potential of your web server with SDPML http://sdpml.mozdev.org/

-----Original Message-----
From: www-html-request@... [mailto:www-html-request@...]On Behalf
Of Oskar Welzl
Sent: 07 December 2005 13:46
To: Jeremy Rand
Cc: www-html@...
Subject: Re: <spoiler> element



Jeremy,

I find it tempting to add the suggested <spoiler> to XHTML 2. I agree
that its use of "show this content only when activated by the user" is
generic enough to be handled by a XHTML element. I agree that the  CSS
+scripting solution is by far not good enough. And I have to say that
@role is not a solution at all:
It might offer a way to tell what the 'spoiler' is. But it is not a way
for an author to clearly tell a browser how to act on the element marked
@role="x:spoiler", given that scripting/CSS might not work as intended
on the UA that renders the page (custom style sheets, no scripting etc).

I have to say, though, that HTML always offered the very generic "show
this content only when activated by the user"-element:
<a href="http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2">Click
here only if you want to read which element it is.</a>

This is as generic as can be - and as specific as we can allow,
probably. It is not the sophisticated "show within the current
page"-solution you want. It does not fully cover all use cases:
Disturbing medical photos within a scientific text should probably be
shown right within the paragraph that describes them, not on a separate
page. But that would be <show-disturbing-medical-pictures>, not just
<spoiler> ;-)

Regards,
Oskar



Am Dienstag, den 06.12.2005, 17:48 -0600 schrieb Jeremy Rand:

> I have a suggestion for an element which could be included in XHTML 2.
> This is a <spoiler> element.  This element would have the content of a
> <spoildesc> element, and a <spoilcontent> element.  The behavior would
> be that when the user agent encounters a <spoiler> element, it should
> render the content of its <spoildesc>, and provide a way for the user to
> activate the <spoiler>.  Once the <spoiler> is activated, the user agent
> should show the content of the <spoilcontent>.
>
> This would be useful in many situations where the user might not want to
> see certain content.  Examples are:
>
> Spoilers of the plot of a book or movie
> Offensive language
> Disturbing medical photos
> Pornographic or otherwise not-safe-for-work content
> The answer to a riddle
> Content with flashing lights that could cause epileptic seizures
>
> I'm sure there are more examples of uses for <spoiler>, but I can't
> think of any more right now.
>
> An example of its usage would be:
>
> <p>Did you hear about the cement mixer that ran over Batman and Robin?</p>
> <p><spoiler>
> <spoildesc>Activate to see punchline.</spoildesc>
> <spoilcontent>It created two new superheroes: Flatman and
> Ribbon.</spoilcontent>
> </spoiler></p>
>
> I know <spoiler> isn't a very good name for it, since there are other
> uses as well, but I can't think of a better name.  I know that <spoiler>
> is implemented into a forum-hosting site's posting system (I can't
> remember which site); it just displays the content of <spoiler> in
> identical foreground and background colors so that you must select the
> text to read it.  Also, I realize that this could be done using either
> scripting or links, but I think links are inappropriate, since the
> content is part of the original document.  I think scripting is
> inappropriate, since this has semantic meaning, so I think it should be
> a standard XHTML element.
>
> Does this proposal sound good?
>
> Thanks,
> Jeremy Rand
>
> PS: Norton E-mail Proxy says this message didn't send properly, so I'm
> sending it again.  Apologies if anyone receives two copies.
>
>
>

[Oskar Welzl]

There are various opinions on this topic; me, myself and I all would
happily add xlink:type="simple" if, in return, we'd get
xlink:type="extended" and external linkbases. If, in return, we'd use
standards in XHTML, rather than home-brew proprietary solutions; the
same standards that are used in Open Document, SVG, XTM, XBRL...
Maybe it's more verbose than people are used to, maybe extended links
and external linkbases are more difficult to implement - but: hey, they
are hoping for UAs to deal with the Metainformation Attributes Module as
well, aren't they?

But, as I said earlier: This topic is probably dead as can be, google
for "xlink xhtml" and you'll find everything has been said and done.
(I like these hopeless cases, though; anybody for a new "@hreflang in
XHTML2"-thread? I still believe Anne got it all wrong in
http://annevankesteren.nl/2004/06/hreflang-and-type ;-)...)

Oskar


Am Mittwoch, den 07.12.2005, 18:10 -0500 schrieb Kelly Miller:

> XLink as it is right now would be very bad for XHTML.  I seriously doubt
> page authors will want to have to declare a simple link EVERY SINGLE
> TIME they want to have a link.
>
> Oskar Welzl wrote:
>
> >Shall we try one more "XLink in XHTML 2.0"?
> >Count my vote. - But I'm afraid I'm too late. Again. :-(
> >  
> >

[Ian Hickson]

On Thu, 8 Dec 2005, Oskar Welzl wrote:
>
> There are various opinions on this topic; me, myself and I all would
> happily add xlink:type="simple" if, in return, we'd get
> xlink:type="extended" and external linkbases. If, in return, we'd use
> standards in XHTML, rather than home-brew proprietary solutions; the
> same standards that are used in Open Document, SVG, XTM, XBRL...

I don't know about the others, but at least in the case of SVG, you can't
use external linkbases. SVG's re-use of XLink is not general re-use, it is
really just a repurposing of the attributes from the XLink namespace.

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

[David Woolley]

>
>
> There are various opinions on this topic; me, myself and I all would
> happily add xlink:type="simple" if, in return, we'd get
> xlink:type="extended" and external linkbases. If, in return, we'd use
> standards in XHTML, rather than home-brew proprietary solutions; the

My impression is that, in the market for which HTML was originally
intended, people are voting with their feet for simpler linking
constructs, in particular [[xxxxx]] and [http://yyyy xxxxx]
in Wiki language (which uses HTML largely presentationally to
achieve relatively semantic documents).  There are probably
similar examples in BBS type applications.

[Anne van Kesteren]

Quoting Kelly Miller <lightsolphoenix@...>:
> Oskar Welzl wrote:
>> Shall we try one more "XLink in XHTML 2.0"?
>> Count my vote. - But I'm afraid I'm too late. Again. :-(

They tried this more or less with SVG. It seems that nobody really understood
the concept of namespaces. Lots of ocntent out there uses xlink:href="" where
xlink is bound to no namespace. The leading product simply assumes that it is
bound to http://www.w3.org/1999/xlink ignoring the fact that the document is
non namespace-well-formed.

And that content quite often generated with some tool...


--
Anne van Kesteren
<http://annevankesteren.nl/>

[Laurens Holst-2]

Anne van Kesteren schreef:

>>> Shall we try one more "XLink in XHTML 2.0"?
>>> Count my vote. - But I'm afraid I'm too late. Again. :-(
>
> They tried this more or less with SVG. It seems that nobody really
> understood
> the concept of namespaces. Lots of ocntent out there uses
> xlink:href="" where
> xlink is bound to no namespace. The leading product simply assumes
> that it is
> bound to http://www.w3.org/1999/xlink ignoring the fact that the
> document is
> non namespace-well-formed.

Oh, what a nonsense! SVG documents are seldom hand-authored, so no-one
ever deals with xlink.

No, the cause of the abuse of the xlink prefix is *exactly* that the
leading product doesn’t have a proper XML parser (fyi: it accepts more
things that are invalid XML, such as <circle> without closing /), and
that because of that authoring tools can (and do) get away with
generating invalid XML. The whole point of XML having strict error
handling is to avoid problems like this.

So the problem you mention isn’t a problem of SVG (or well, it has
become one), nor an authoring problem with regard to namespaces, as you
claim it is, but a problem of broken XML parser implementations which
ignore the standard. Actually, we can’t really call them XML parsers.
They’re more like ‘X-markup with arbitrary error handling’ parsers.

HTML inherently has this problem. XML languages don’t, but this once
again demonstrates that the parsers really really need to do strict
processing for that to work. If they don’t, there’s no point in using
XML at all.


~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.