Re: [whatwg] several messages about the HTML syntax

[fantasai]

On 03/02/2008 03:02 PM, Ian Hickson wrote:


On Tue, 31 Jul 2007, Philip Taylor wrote:


IE undocumentedly recognises some which nobody else does:

aafsU+206D  ACTIVATE ARABIC FORM SHAPING
ass U+206B  ACTIVATE SYMMETRIC SWAPPING
iafsU+206C  INHIBIT ARABIC FORM SHAPING
iss U+206A  INHIBIT SYMMETRIC SWAPPING
lre U+202A  LEFT-TO-RIGHT EMBEDDING
lro U+202D  LEFT-TO-RIGHT OVERRIDE
nadsU+206E  NATIONAL DIGIT SHAPES
nodsU+206F  NOMINAL DIGIT SHAPES
pdf U+202C  POP DIRECTIONAL FORMATTING
rle U+202B  RIGHT-TO-LEFT EMBEDDING
rlo U+202E  RIGHT-TO-LEFT OVERRIDE
zwspU+200B  ZERO WIDTH SPACE

(I believe that list is complete.)

The first eleven were suggested on
https://listserv.heanet.ie/cgi-bin/wa?A2=ind9605&L=html-wg&P=4579 some
time ago but don't seem to have gone very far (except into IE).

I can see some legitimate users at
 and
 and maybe there's a few dozen or hundred
more elsewhere (but I can't measure it easily). There's some in text-art
at  and quite a
lot in weird places like
 or
 that I don't understand
but that seem to all be on 2channel (or copied from it). I've no idea
how common they are in general.

Are these used significantly on the web, or would they be considered
highly useful if anyone knew they existed, or should HTML5 just ignore
them?


I'm very skeptical about introducing entities for the codes that are
redundant with dir="" and  (namely, lre, lro, pdf, rle, rlo).


I agree 100% with this rationale.


I don't know enough about the others to have an educated opinion. I can
set up a search to examine the data in more detail.


I don't know much about the others, but I can provide some info on ZWSP.
It is (as specced) equivalent to . Specifically, it
  * defines a word break (line-breaking opportunity)
  * thereby breaks Arabic joining

For contrast:
  ZWSP - Breaks a word (and therefore also Arabic joining) with no visible 
space.
  ZWJ  - Not a word break. Forces joining behavior.
  ZWNJ - Not a word break, but breaks joining.

ZWJ and ZWNJ are primarily useful for Arabic and other shaped scripts. I'm
not sure of the common uses for ZWJ, but ZWNJ is frequently used in Persian
to visually separate grammatical prefixes from the rest of the word (without
breaking the word or introducing extra space).

ZWSP is more likely to be used in Thai and related scripts, to define word
boundaries. Thai does not use spaces between words, so break opportunities
need to either be marked with ZWSP or found with a dictionary. Even in the
presence of automatic dictionary-breaking, however, there are ambiguous
cases which will need ZWSP to show the correct break-point.

There's further discussion about this in
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=13108
I've no comment on concerns about compatibility with XML, but I can say
that I've typed &zwsp; multiple times expecting it to work and find it
surprising that ‍ and ‌ work, but &zwsp; does not...

~fantasai

Re: [whatwg] several messages

[Ian Hickson]

On Thu, 18 Mar 2010, Alex Bishop wrote:
>
> In the processing model for image maps (section 4.8.13.2), step 8 of the 
> processing instructions for area elements says that if the shape 
> attribute is in the Circle state:
> 
> > Let x be the first number in coords, y be the second number, and r be 
> > the third number.
> > 
> > The shape is a circle whose center is x CSS pixels from the left edge 
> > of the image and x CSS pixels from the top edge of the image, and 
> > whose radius is r pixels.
> 
> Surely "x CSS pixels from the top edge of the image" should read "y CSS 
> pixels from the top edge of the image"?

On Thu, 18 Mar 2010, Ashley Sheridan wrote:
> 
> I think the x here indicates an arbitrary number rather than units along 
> the y-axis.

On Fri, 19 Mar 2010, Tab Atkins Jr. wrote:
> 
> No, the first sentence of the quote Alex gives makes it clear that "x" 
> has a definite meaning, along with "y" and "r".  The spec has a typo - 
> the distance from the top edge should indeed be "y" pixels, as that is 
> the second number in the @coords attribute.

Fixed.

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

Re: [whatwg] several messages

[Ian Hickson]

On Thu, 18 Mar 2010, Simon Pieters wrote:
> On Thu, 18 Mar 2010 01:03:33 +0100, Ian Hickson  wrote:
> > On Mon, 22 Feb 2010, Kornel Lesi�~Dski wrote:
> > > 
> > > I'm wondering if data-* attributes should be renamed to priv-* to 
> > > make it clearer that it's page's _private_ data.
> > > 
> > > "data-" is such a nice generic prefix that I'm afraid sooner or 
> > > later someone will start basing microformats-like markup on that.
> > 
> > It's not a bad idea... Unfortunately data-* is already being used 
> > quite a lot and has been widely advertised, so we have to be careful 
> > with this. Anyone else have an opinion on this?
> 
> I think we should keep data- as is. People have started to use it, we 
> would waste their time by renaming it.

On Thu, 18 Mar 2010, Henri Sivonen wrote:
> > 
> > I don't feel strongly that either name is better. Though I would not 
> > that priv- doesn't make things much clearer since it's totally 
> > undefined who it's private to.
> 
> Given that priv-* isn't clearly better, I think it would be better not 
> to annoy early adopters of data-* with a name change.

On Thu, 18 Mar 2010, Jonas Sicking wrote:
> 
> Agreed.

I haven't changed it.


On Wed, 30 Jun 2010, Tab Atkins Jr. wrote:
>
> In the first paragraph of 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data
>  
> it says that a custom data attribute is "an attribute in no namespace 
> whose name starts with the string "data-", has at least one character 
> after the hyphen,...".  Following this,  would not put 
> anything in .dataset.
> 
> However, in the algorithm for getting the list of name-value pairs, it 
> says to process "each content attribute on the element whose first five 
> characters are the string "data-" and whose remaining characters (if 
> any)...".  Following this,  would make 
> .dataset[""]="foo".
> 
> One of these references needs to be fixed, as webkit is implementing 
> dataset right now.

There's no contradiction here, it's just a difference between author 
conformance and implementation requirements in error conditions.

Since WebKit implemented this as specced, I've left it unchanged:

   https://bugs.webkit.org/show_bug.cgi?id=41146

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

Re: [whatwg] several messages

[Jonas Sicking]

On Thu, Sep 3, 2009 at 7:41 AM, Ian Hickson wrote:
> On Mon, 31 Aug 2009, Jonas Sicking wrote:
>> >
>> > Upon further consideration I've renamed getStorageUpdates() to
>> > yieldForStorageUpdates().
>>
>> 'yield' usually refers to halting execution. I would expect the above
>> name to stop the current thread and allow other threads to run. While
>> that is what could be happening here, I'm not sure that is the primary
>> function of the call.
>
> It's more or less exactly what the method does, no?

I think the common case is that no other thread is blocked, and we'll
simply drop the lock on the storage mutex and continue execution of
the current thread.

Compare this to the Javascript 1.8 keyword 'yield', which always stops
execution of the currently running code. Granted, Javascript 1.8 is
Firefox only at this point, however I think the hope is that it'll get
implemented across more browsers eventually.

>> I really liked Darin's (?) suggestion of allowStorageUpdates as that
>> seems to exactly describe the intended use of the function. We no longer
>> prevent other page from updating the storage.
>
> "allow" implies a state change, which I don't think really matches what is
> happening here. ("How do I disallow updates?")

I don't understand why you associate "allow" with "state change"? It
could just as well be allowing anything else. The word "Updates" is
much more associated with "state change" i'd say. And that word occurs
in your proposal too. Really it should probably be allowStorageAccess
or yeildForStorageAccess to be more correct.

/ Jonas

Re: [whatwg] several messages

[Ian Hickson]

On Mon, 31 Aug 2009, Jonas Sicking wrote:
> >
> > Upon further consideration I've renamed getStorageUpdates() to 
> > yieldForStorageUpdates().
> 
> 'yield' usually refers to halting execution. I would expect the above 
> name to stop the current thread and allow other threads to run. While 
> that is what could be happening here, I'm not sure that is the primary 
> function of the call.

It's more or less exactly what the method does, no?


> I really liked Darin's (?) suggestion of allowStorageUpdates as that 
> seems to exactly describe the intended use of the function. We no longer 
> prevent other page from updating the storage.

"allow" implies a state change, which I don't think really matches what is 
happening here. ("How do I disallow updates?")


On Mon, 31 Aug 2009, Mike Wilson wrote:
> 
> Is there a preference for having the name indicate
> that "we" are finishing our own transaction, ie
>   myStorageUpdatesAreNowComplete
>   endStorageUpdates
>   finishStorageUpdates
>   commitStorageUpdates
>   flushStorageUpdates
>   saveStorageUpdates
> or should it indicate that "others" are now welcome
> to do their stuff, such as in:
>   otherPagesStorageUpdatesAreNowWelcome
>   allow(Other)StorageUpdates
>   enable(Other)StorageUpdates
> ?

I think we want more the second, but with shorter names.

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

Re: [whatwg] several messages

[João Eiras]

The ImageData APIs already provide the ability to do this and are
already supported by Firefox, Opera and Safari.


Given the ImageData APIs, and given that they are generally more efficient
at the typical use cases for getPixel/setPixel, I haven't added getPixel/
setPixel to the spec.

Cheers,


The opera-2dgame context also has APIs for collision detection and control 
painting
http://my.opera.com/WebApplications/blog/show.dml/200788
I'm not familiar with the current canvas spec, but are these features supported 
somehow? Or would they have the potential to be included ?

Re: [whatwg] several messages

[Ian Hickson]

On Tue, 7 Apr 2009, Jeff Creamer wrote:
>
> Hi.  Since March of '06, Opera 9 has supported a custom extension to the 
> canvas context called "opera-2dgame." Importantly, their extension adds 
> these methods:
> 
> getPixel(x, y)
> Returns the pixel value (colour, opacity) at (x, y). Returned in the 
> form #rrggbb if fully opaque and rgba(r, g, b, a) if it has some alpha 
> transparency.
> 
> setPixel (x, y, color)
> Allows you to set the colour of the pixel at (x, y). The third argument 
> should be a CSS color - you could provide a string such as `red', a HTML 
> colour code or even a rgba() value.
> 
> I don't see any recent discussion of this.  And I am also aware that the 
> canvas drawing model is not pixel-oriented.  Nonetheless, mightn't these 
> functions be extremely useful?  As the Opera folk point out, they bless 
> game developers, and it occurs to me that they could be used for other 
> neat, useful things, such as giving JavaScript a rudimentary RAM drive.  
> Description including several demo programs and a discussion of security 
> issues is available here.
> 
> Why not make getPixel () and setPixel() a standard?

On Tue, 7 Apr 2009, Oliver Hunt wrote:
>
> The ImageData APIs already provide the ability to do this and are 
> already supported by Firefox, Opera and Safari.

Given the ImageData APIs, and given that they are generally more efficient 
at the typical use cases for getPixel/setPixel, I haven't added getPixel/ 
setPixel to the spec.

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

Re: [whatwg] several messages

[Ian Hickson]

On Fri, 6 Mar 2009, Rikkert Koppes wrote:
>
> The example presented at the section element definition [1]. The given 
> markup could be ok, however, with a look at the actual contents (a nice 
> essay about apples), the h1 elements found in the section elements 
> should actually be h2 elements, giving rise to the folowing document 
> structure:
> 
> Apples
> - Red Delicious
> - Granny Smith

On Fri, 6 Mar 2009, Lachlan Hunt wrote:
> 
> No, the example is correct.  It's actually illustrating how you can use 
> h1 elements in combination with the section elements to achieve the same 
> structure.  See the section on headings and sections and creating an 
> outline for more info.

I've added more explanatory text on the matter after that example.

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

Re: [whatwg] several messages about and related subjects

[Ian Hickson]

On Mon, 25 Feb 2008, Maciej Stachowiak wrote:
> On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
> > 
> >   
> >  This would preclude any sane way of putting form controls in
> >  legends, which would be bad.
> >  This can't be fixed in the spec.
> 
> Is the ability to put form controls in figure captions (let alone more 
> than one form control) really more important than ability to style them 
> sanely? Putting a form control in a figure caption seems unlikely to me. 
> Even more so for , where form controls inside the label would 
> be confusingly inside another interactive element. Indeed,  is 
> arguably a kind of form control.

It's easy to imagine UIs, e.g. of templates, that have text boxes in 
captions and are waiting for user input there. The default "open file" 
dialog on Mac OS X has a kind of -like UI with a control in the 
"caption", too. And finally,  already has so many semantics and 
special rules and so forth that reusing it here just seems like a 
particularly bad idea.


> >   
> >  Parsing issues in Firefox and IE:
> > 
> > http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfieldset%3E%0A%20...%0A%20%3Cfigure%3E%0A%20%20%3Clegend%3Efigure%3C%2Flegend%3E%0A%20%20content%0A%20%3C%2Ffigure%3E%0A%20...%0A%3C%2Ffieldset%3E
> >  ...and the element doesn't appear in the DOM when there's no
> >   in at least Safari and Firefox.
> 
> It seems to me that the problems with adding a new element are purely 
> aesthetic, while the problems with reusing 'legend' are practical and 
> harm deployment of the new element.

I don't think we should discount the problems with introducing a new 
element quite that quickly.


> > I think our only option is to use , and, while in the 
> > migration period, have people use markup like:
> > 
> >   
> >  ... 
> > ...
> >   
> > 
> > ...with styles like:
> > 
> >   figure > legend, figure > .legend { ... }
> 
> Yuck. Surely writing  ...  
> is uglier than writing something like  ... .

Yes, but the former would only last a decade or two, while the latter 
would last for the lifetime of HTML.


> > > 4) Another alternative would be using a new unknown element. 
> > > Whipping out my thesaurus, I see , . Another 
> > > possibility is something like  (to avoid the problems 
> > >  would cause for figures inside tables), but that wouldn't 
> > > be a good fit for .
> > 
> >  and  and so on just seems like it would 
> > make the language really complicated.
> 
> But  is pretty reusable and about as semantically correct as 
>  for general use as a caption:
> 
> http://dictionary.reference.com/browse/rubric
> http://dictionary.reference.com/browse/legend

Except people don't know what a rubric is. They know what a legend is. 
"Legend" is what people call this (or "caption", but the parsing issues 
there are even more intractable).


> > We've waited years for , can't we wait a few more while 
> > browsers get their act together in their parsers?
> 
>  could be used right now with CSS styling as backup and without 
> polluting up the markup if it didn't rely on an aspect of the HTML5 
> parsing algorithm that no browser implements yet. Otherwise we will 
> indeed have to wait years, needlessly.

I think the cost of a few years here is worth it. It's not like this is 
 where introducing this feature today is ten years too 
late; the  element is helpful, and worth adding, but not a 
panacea. Thus I don't see the problems as a big deal.

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

Re: [whatwg] several messages about tables and related subjects

[Kristof Zelechovski]

The advantage of having an attribute referring to the current column of
every table element is that it is easier to check that the right data are
the right column.  Columns are filled sequentially but the exact position in
the sequence is accidental and meaningless in most cases.  I tend to put the
column keyword into the title attribute; this allows me to verify that the
keywords are in the right order.  This is verbose but it greatly improves
source code readability.  I think the abbr attribute could be used for this
purpose as well (repeated on every cell).
What do you think?
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Thursday, August 21, 2008 11:16 AM
To: Tab Atkins Jr.
Cc: whatwg List
Subject: Re: [whatwg] several messages about tables and related subjects

On Mon, 24 Mar 2008, Tab Atkins Jr. wrote:
>
>  >> TH and TD
> >> * abbr (I think that's supported by screen readers, but need to verify)
> >
> >I don't really see that these attributes actually help anyone.
> 
> I don't have a screen reader to verify, but afaik abbr= is used to provide
a
> shortened form of the header when it is spoken aloud repeatedly.  Leaving
it
> out won't *hurt* anything, but the annoyance of hearing a large bit of
> header repeated over and over again when the table is complex enough to
> *need* a regular reminder would be enough, I think, for abbr= to be
> considered to help people.
> 
> I use abbr= to this effect in my own tables.

I understand the intent, but wouldn't it be better for the user agent to 
automatically abbreviate the table headers, for example by only saying the 
first few syllables of the first bit of unique text in the relevant 
headers once it has been said several times?

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

Re: [whatwg] several messages about tables and related subjects

[Ian Hickson]

On Thu, 21 Aug 2008, Pawe�~B Stradomski wrote:
> 
> I guess it's to difficult to implement such guessing right.
> 
> 
> 
>   Amount sold in Europe
>   Amount sold in Asia
>   Amount sold in North America
> ..
> 
> 

This example would be fine, the UA could easily strip common leading text 
and just say "Europe", "Asia" and "North Am" each time. (Stripping leading 
common text is a solved problem.)


> Another example (translated into English and simplified from real life 
> Polish text):
> 
> Camp details
> 
> 
>   
>   Camp for young scouts (12-15 years old)
>   Training camp for scout leaders (16-18 years 
> old)
> ..
> 
>
> [...]

In this example, the same algorithm would end up saying "Camp for" and 
"Training" as the two headers, but I think that's ok (if not necessarily 
ideal), since the user will know from having heard the full header several 
times that "Camp for" is short for the young people column and "Training" 
is short for the leaders column.


> Please don't remove this attribute, it doesn't hurt people who don't 
> care about using it, but might make it more difficult for disabled 
> people. Hearing same sentence over and over can kill usability.

It's wrong to think that attributes that no-one use (and research 
indicates that this attribute really isn't used at all) don't cause harm. 
Every part of the language that we have increases the cognotive load of 
the entire language. A language with one feature is simpler to learn than 
a language with one feature and six unused features.

I agree entirely that abbreviating long headers is something that should 
happen. But it should happen for _all_ tables, not just those written by 
conscientious authors.

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

Re: [whatwg] several messages about tables and related subjects

[Paweł Stradomski]

W liście Ian Hickson z dnia czwartek 21 sierpnia 2008:
> > I don't have a screen reader to verify, but afaik abbr= is used to
> > provide a shortened form of the header when it is spoken aloud
> > repeatedly.  Leaving it out won't *hurt* anything, but the annoyance of
> > hearing a large bit of header repeated over and over again when the table
> > is complex enough to *need* a regular reminder would be enough, I think,
> > for abbr= to be considered to help people.
> >
> > I use abbr= to this effect in my own tables.
>
> I understand the intent, but wouldn't it be better for the user agent to
> automatically abbreviate the table headers, for example by only saying the
> first few syllables of the first bit of unique text in the relevant
> headers once it has been said several times?

I guess it's to difficult to implement such guessing right.



Amount sold in Europe
Amount sold in Asia
Amount sold in North America
..



Another example (translated into English and simplified from real life Polish 
text):

Camp details



Camp for young scouts (12-15 years old)
Training camp for scout leaders (16-18 years 
old)
..



Price
xx
yy


Location details
xx
yy

...




Please don't remove this attribute, it doesn't hurt people who don't care 
about using it, but might make it more difficult for disabled people. Hearing 
same sentence over and over can kill usability.


-- 
Paweł Stradomski

Re: [whatwg] several messages about tables and related subjects

[Ian Hickson]

On Mon, 24 Mar 2008, Tab Atkins Jr. wrote:
>
>  >> TH and TD
> >> * abbr (I think that's supported by screen readers, but need to verify)
> >
> >I don't really see that these attributes actually help anyone.
> 
> I don't have a screen reader to verify, but afaik abbr= is used to provide a
> shortened form of the header when it is spoken aloud repeatedly.  Leaving it
> out won't *hurt* anything, but the annoyance of hearing a large bit of
> header repeated over and over again when the table is complex enough to
> *need* a regular reminder would be enough, I think, for abbr= to be
> considered to help people.
> 
> I use abbr= to this effect in my own tables.

I understand the intent, but wouldn't it be better for the user agent to 
automatically abbreviate the table headers, for example by only saying the 
first few syllables of the first bit of unique text in the relevant 
headers once it has been said several times?

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

Re: [whatwg] several messages about , , , and related subjects

[Ian Hickson]

On Tue, 26 Feb 2008, Tab Atkins Jr. wrote:
> >> > - LH (caption for list! A must-have)
> >>
> >> Why not using the title attribute?
> >
> >Actually with  the  element is now better handled using
> > and .
> 
> Using  and :
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('figure')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfigure%3E%0A%20%20%3Clegend%3EList%20title%3C%2Flegend%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A%3C%2Ffigure%3E
> While this isn't horrible, it isn't supported properly, as noted before.  FF
> currently just ignores the fact that there's a  tag at all and
> treats the list title as a plain text node.  IE7 treats the  as an
> unknown tag and the title as a plain text node, even if you try to apply the
> createElement shim.
>
> Using :
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lh')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%20%20%3Cul%3E%0A%20%20%20%20%3Clh%3EList%20title%3C%2Flh%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0A%20%20%3C%2Ful%3E%0A
> On the other hand,  seems to be supported just fine in FF *and* IE7
> (with the shim).  This solution is usable *immediately*, which is a big
> plus.  Since we only want to allow a single header per list, though, I'd
> prefer fully embracing the parallel with  and naming this element
> , thus implying it must come first and at most once.

It's true that  has support problems, but these are fixable on the 
long run (indeed the HTML parser requires that they be fixed, so either 
this will eventually work, or we'll have to fix the parser and can revisit 
this then). Adding a new element here is something I really want to avoid 
because we already have half a dozen different ways to mark up titles, 
captions, legends, labels, titles, and the like, and adding more just 
seems silly.


> At this point, though, why not just bend the definition of  and  and
> allow  tags directly?  Both FF and IE7 form good DOM trees with this
> markup.
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('lhead')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0D%0A%20%20%3Cul%3E%0D%0A%20%20%20%20%3Ch1%3EList%20title%3C%2Fh1%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%20%20%3Cli%3EList%20item%3C%2Fli%3E%0D%0A%20%20%3C%2Ful%3E%0D%0A
> This solution doesn't seem to have a drawback, really.  It's already
> supported (*without* an IE shim), doesn't require the creation of a new
> element, and is completely intuitive.  Just specify (like thead) that it
> must be at the start of the list, and can occur at most once.

This would address the problem for  and , but wouldn't solve the 
problem for all markup. The  solution is more generic.

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

Re: [whatwg] several messages

[Ian Hickson]

On Thu, 12 Jun 2008, Jorge Bay Gondra wrote:
>
> I was trying to imaging how it would be to build a site, and I realized 
> that, in the case of site with 2 nav bars (typically 2 sidebars) there's 
> not a way to specify which is the "main" sidebar and which is 
> accessory... What do you think about specifying hierarchy for navs 
> elements?

On Fri, 13 Jun 2008, James Graham wrote:
> 
> Arguably the outline algorithm already does this, since it places  
> elements in a hierarchy along with other sections. For any case not 
> covered by the outline algorithm I think that there would need to be 
> some very strong use cases to add explicit markup here; what kind of UA 
> features did you have in mind, and how well would they work if the 
> markup was missing or incorrect on most pages?

I agree with James here, what is the use case?


On Thu, 12 Jun 2008, Jorge Bay Gondra wrote:
>
> Note: In the nav sample ( 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav)
>  
> that includes several places with links, should be a good idea that the 
> header and footer list of links have to be represented in an unordered 
> list ul..., and not in a paragraph (!?), do you agree?

Doesn't really matter either way. Do can do whatever you like. :-)

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

Re: [whatwg] several messages

[Kristof Zelechovski]

In this particular case, the author assumes that the browser does not show
the image but informs the user that it can be downloaded.  This text makes
no sense if the image is already displayed.  
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Wednesday, July 30, 2008 4:50 AM
To: Nicholas Shanks; Benjamin Hawkes-Lewis; Anne van Kesteren
Cc: Simon Pieters; WHAT Working Group Mailing List
Subject: Re: [whatwg] several messages

On Wed, 21 Mar 2007, Anne van Kesteren wrote:
> 
> > I guess we have to agree to disagree here, but I think
> > Download Foo 1.4(12  > title="Megabytes">MB)
> > is preferable to
> > 
> > which it would appear you prefer.
> 
> Yeah. An abbreviation such as MB should be known by an accessibility 
> client anyway and I think it's also perfectly capable of dealing with a 
> few parenthesis. Besides, the latter has been standard practice for over 
> a decade and trying to change authoring habbits with respect to that now 
> seems silly. Besides, you can use  if you really care about 
> "proper" fallback.

In any case, what's the image in the case above? Why would you ever want 
that text _not_ visible when the image was visible?
   

Re: [whatwg] several messages

[Ian Hickson]

On Tue, 20 Mar 2007, Nicholas Shanks wrote:
> 
> I asked for the resurrection of HTML+'s fallback element 
> last month. The reasons I cited were exactly the same as the reasons 
> being given now in favour of the  element, however I was told 
> (paraphrasing) "Why bother, you can just use " and "That would 
> break existing implementations" (though no such implementations were 
> cited).
>
> So again, I ask for an  element to replace . Benefits include:
> - As  would cater for video/* MIME types,  would cater for
> image/*

I don't see how this is a benefit over .


> - The alt and longdesc attributes can be part of the fallback content,
> allowing markup.

If you need markup in the fallback, use . (Or, better, consider 
exposing the content to everyone and not making it only available to those 
who don't see the image.)


> - You don't have to provide a type attribute and match on: object
> [type^="image/"]

Seems like "img" handles this too.


On Wed, 21 Mar 2007, Nicholas Shanks wrote:
> On 21 Mar 2007, at 00:27, Simon Pieters wrote:
> > 
> > The  start tag is parsed as if it were , so you would get 
> > both the image and the fallback with HTML+ markup. Existing content 
> > rely on this behaviour, which is why it was added to the Parsing spec 
> > (see "A start tag whose tag name is "image"", and see comment in 
> > source).
> 
> So what's the problem?
>
> Content with a doctype of  or  is 
> treated correctly, and content without a doctype is handled in quirks 
> mode, where the UA can look for  and if found in a suitable 
> place, treat the start tag as , or if not found, treat the start 
> tag as . Any content using  in strict mode with another HTML 
> doctype is broken anyway, so it doesn't really matter how that looks.

We're not doing any DOCTYPE-based parsing differences unless we 
_absolutely_ have to. This kind of switch is a giant source of 
implementation bugs and authoring problems.


On Wed, 21 Mar 2007, Benjamin Hawkes-Lewis wrote:
> 
> Or, how about getting more specific?
> 
>  [e.g. image/gif of an icon]
>  [e.g. image/svg of a map]
>  [e.g. image/jpeg of a cat]
> 
> Would that help search engines, I wonder?

I don't see why it would (who would be making sure the right one was used 
each time?).

This really doesn't seem to solve a real problem.


On Wed, 21 Mar 2007, Anne van Kesteren wrote:
> 
> > I guess we have to agree to disagree here, but I think
> > Download Foo 1.4(12  > title="Megabytes">MB)
> > is preferable to
> > 
> > which it would appear you prefer.
> 
> Yeah. An abbreviation such as MB should be known by an accessibility 
> client anyway and I think it's also perfectly capable of dealing with a 
> few parenthesis. Besides, the latter has been standard practice for over 
> a decade and trying to change authoring habbits with respect to that now 
> seems silly. Besides, you can use  if you really care about 
> "proper" fallback.

In any case, what's the image in the case above? Why would you ever want 
that text _not_ visible when the image was visible?
   
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] several messages about URLs

[Ian Hickson]

On Tue, 13 Mar 2007, L. David Baron wrote:
>
> The wording of the value of href for base elements [1] is not quite the 
> same as the wording for anchor elements [2], and technically [3] that 
> wording allows only absolute URIs.  They should probably both say they 
> allow URI references (or IRI references), and the former should probably 
> say "be" or "equal" rather than the rather vague "contain".  (I suspect 
> there are similar problems elsewhere.)
> 
> Or, if you don't like using the term "URI reference" everywhere (which 
> may be worth avoiding), you should at least explain your usage in the 
> Terminology section with reference to terms defined in the URI/IRI RFCs.

I've done a huge rewrite of everything URL-related now which should 
resolve all these issues and make everything consistent and (hopefully) 
realistic.


On Tue, 13 Mar 2007, L. David Baron wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/#terminology says:
>   # For readability, the term URI is used to refer to both ASCII 
>   # URIs and Unicode IRIs, as those terms are defined by [RFC3986]
>   # and [RFC3987]  respectively. On the rare occasions where IRIs 
>   # are not allowed but ASCII URIs are, this is called out
>   # explicitly.
> This is rather misleading, since backwards compatible use of URIs is
> not ASCII-only.  While IRIs are a superset of conformant URIs, IRIs
> are a subset of real-world-URIs, since they have the encoding fixed
> to UTF-8.  Backwards-compatible URI handling tries to send the same
> sequence of bytes that was in the document back to the server,
> percent-encoded byte-by-byte, by encoding the URI based on the
> encoding of the document.

It's mildly more complicated than that, it seems, since path components 
always seem to use UTF-8 and query components use the doc encoding, but in 
any case, the spec now specified this.


On Wed, 14 Mar 2007, Peter Karlsson wrote:
> 
> Indeed. Considering the number of partly contradicting bug reports we 
> have here at Opera on the issue, it would be nice to have it clearly 
> spelled out, so that everyone is doing the same thing, and that we are 
> doing what the user expects.

Please let me know if the spec, as it stands, is acceptable.

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

Re: [whatwg] several messages

[Kristof Zelechovski]

The intended result of printing a document is that there is a printed copy
of a reasonable quality available.  The Web page can have no knowledge of
that fact (unless it has feedback from the surveillance network, that is).
Assuming that it is there after printing is wishful thinking.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Friday, June 06, 2008 2:12 AM
To: [EMAIL PROTECTED]
Subject: Re: [whatwg] several messages

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!

Re: [whatwg] several messages

[Ian Hickson]

On Sun, 17 Jul 2005, Dean Edwards wrote:
>
> Anne van Kesteren wrote:
> > Shouldn't the print method on the window DOM interface be defined as well?
> > 
> > Example: print
> 
> IE has some nice onbeforeprint/onafterprint events. Can we add these 
> too?

Defined both.


On Mon, 18 Jul 2005, Olav Junker Kjær wrote:
> 
> Arent these event mostly used to transform the view before printing it? 
> I think this is better handled by a print-specific style-sheet today.

There are some things for which CSS just doesn't work, sadly.


On Tue, 19 Jul 2005, Greg Kilwein wrote:
> > DG wrote: 
> >
> > a) my invoice format requires a timestamp that says something like 
> > this: printed by [person] on [timestamp].
> > 
> > b) To capture the essence of the browsing session, I would like to 
> > build a breadcrumb at the bottom of the printed page, displaying 
> > titles and urls of pages the user have visited on the site during this 
> > visit.

This is now possible.


> I'll add another case: the onafterprint event could be used in a 
> "wizard"-style application where printing some document is step 3 of 10, 
> for example.  The application could proceed to the next step (not 
> necessarily a different document) automatically without requiring a 
> button that says "click here when done printing".  That's a case that a 
> media-specific stylesheet cannot handle.  Automating tasks and reducing 
> clicks are both high priorities in my development of web applications.

Good use case!


> If the ability to set printer settings such as portrait/landscape is 
> available, an "onbeforeprint" event could be used to prompt the user 
> whether they'd like to automatically switch their paper orientation to 
> portrait or landscape before printing.  (The same can be said for 
> margins and headers/footers.)  This can be done in the print dialog, but 
> if it is truly important to how the page prints, a separate step that 
> highlights the importance of the print setting to the user would be 
> helpful in reducing calls to my company's tech support line.

As specified, you could indeed use showModalDialog() for this.


[snip other use cases]

On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>Once again, I don't understand why you can't simply provide the user 
> with a button on the web page that either calls up a printable version 
> or clones the document so that the clone can be used for printing. 
> (Granted, there probably isn't support for the latter, but it makes more 
> sense to standardize that than to add onbeforeprint and onafterprint, 
> especially when you consider the fact that a clone of the document can 
> be held in memory for repeated printing or dumped.)

I don't see why we shouldn't have both; after all, people are using 
onbeforeprint today, and it doesn't seem to have caused a disaster or 
anything.


>As far as I can tell, no part of WF2 or WA1 encourages malicious 
> behavior on the part of the webmaster against the users. In fact, part 
> of the problem I had with  was that it could, in theory, be 
> use in a hostile way towards legacy user agents. Therefore, I doubt this 
> will ever make it into a WHATWG spec, especially when it can interfere 
> with simple things like printing selected text, et cetera.

This hasn't happened much, but certainly a user agent could disable 
scripts while it is printing.


>Now you've completely lost me, use-case-wise. On an intranet, why is 
> a printable version of the document not an acceptable workaround?

Well it's not as nice, is it. I mean, it's not the same experience really. 
Look at printing in Google Maps, for instance, where it brings up another 
page -- it's not as seamless as just printing the current page.


>Here's a question for you to chew on: What happens if you want to 
> print and the webmaster screwed up something in the onbeforeprint or 
> onafterprint event? Will it effectively disable printing? Will the 
> document be restored once printing is finished? What if it's an AJAX 
> application and the UI of the app is hidden for printing but never 
> restored?

This can all happen without printing too.


On Wed, 20 Jul 2005, Matthew Raymond wrote:
> 
>I think there's good enough reason to disallow a feature when you 
> have the following:
> 
> 1) The feature can be abused.
> 
> 2) It alters the standard behavior of the browser.
> 
> 3) It can be easily disabled with a modified open source browser or 
> browser extension.

...or the browser can just allow it to be overriden. Point 3 basically 
counteracts the first two, imho.


> 4) Its use cases are partially covered by CSS.

CSS is just as susceptible to 1 and 2, why isn't that a problem?


> 5) There are existing workarounds.

Workarounds are just that. Not solutions.


> 6) An alternative has been proposed that has less potential for abuse, 
> is more powerful, and doesn't change basic browser functionality.

I don't see how it has less potential for abuse, really. I also am not 
sure 

Re: [whatwg] several messages about handling encodings in HTML

[Ian Hickson]

On Tue, 4 Mar 2008, �istein E. Andersen wrote:
> On Fri, 29 Feb 2008 01:21:20 + (UTC), Ian Hickson wrote:
> 
> > (I've made the characters not allowed in XML also not allowed in HTML, 
> > with the exception of some of the space characters which we need to 
> > have allowed for legacy reasons.)
> 
> The C1 character U+0085 NEXT LINE (NEL) is also a Unicode space 
> character, and this one is neither disallowed nor discouraged in XML as 
> far as I can tell.  I am not sure if we really want to support this 
> character, though; Opera, Safari and Firefox do not seem to recognise it 
> at all, and one IE7 installation seems to treat it as a non-breakable 
> wide space, but this may well be font-dependent.  (Allowing this 
> character could be confusing given that … does not refer to U+0085, 
> but rather to an ellipsis for compatibility with Windows-1252.)

I consciously excluded it.


> More importantly, the current draft seems to allow C0 (not only white 
> space) controls and delete, as well as U+FDD0 to U+FDDF and the 
> non-characters *FE and *FF when these are expressed as character 
> references.  Would it be possible to (dis)allow the same set of 
> characters in both cases?

Yeah, this was fixed yesterday.

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

Re: [whatwg] several messages about

[Ian Hickson]

On Wed, 16 Apr 2008, Shannon wrote:
> Ian Hickson wrote:
> > 
> > We're not talking about making class meaningful. I'm not sure I 
> > understand what you are arguing against at this point.
> > 
> > The proposal is just that authors should use class="" to distinguish 
> > the various ways they use  so that they can (e.g.) style them 
> > differently. Where is the spec unclear? I should rewrite it to avoid 
> > any ambiguities.
> 
> The spec is fine.

Ah, ok. Well then good!


> > > It's subclassing: the general is sufficient, the specific better. 
> > > Many markup languages use the design, and in this case, I think it's 
> > > necessary.
> >
> > The class="" attribute can handle this case.
> 
> We appear to be talking about "lookups", "script", "semantics" and 
> "markup" here rather than "style"; presumably to create custom link 
> behaviours and assist in automated document processing. Perhaps there is 
> an assumption that processing will only occur within the scope of the 
> current page or site (and presumably therefore under the control of a 
> single entity).

Right. I don't think anyone is suggesting that we need to classify  
elements in a globally unique and unambiguous way -- what would be the use 
case for that?


> However if  were to have a type then it's likely that the first 
> systems to take advantage of it would be search-engines and catalogues.

As someone who works for a search engine company, I highly doubt that. :-)


> Using a type/rel/category attribute instead of class will assist in 
> automated document processing and categorisation. It doesn't really 
> matter whether a list of allowed types is defined or not since a 
> search/directory crawler would probably deal with the uncommon or 
> unsupported exceptions. But lumping the type of citation in with the 
> class names used to style it is simply asking for trouble since it will 
> also trigger any defined styles (probably unintentionally) and/or create 
> nonsense categories like "book_class" in the processors' DB. I could 
> imagine such a situation leading to the following catalogue output:
> 
> This article contains:
> - 4 book citations
> - 2 book_class citations
> - 1 squiggly_underline citations
> 
> Hope that makes my position on this clearer. If I misunderstood 
> somebodies comments then I apologise.

I agree that class="" won't work for this as a globally unique solution 
(short of a Microformat being developed for it). However, I don't think we 
need to find a globally unique solution, as the use cases for such a 
solution aren't especially compelling.

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

Re: [whatwg] several messages about

[Shannon]

Ian Hickson wrote:



We're not talking about making class meaningful. I'm not sure I understand 
what you are arguing against at this point.


The proposal is just that authors should use class="" to distinguish the 
various ways they use  so that they can (e.g.) style them differently. 
Where is the spec unclear? I should rewrite it to avoid any ambiguities.
  


The spec is fine. I was referring to the discussion about adding a TYPE 
attribute for . Repeated below.



Anne van Kesteren wrote:
  

> > Ian Hickson wrote:
> > 

> > > > Then would you want different markup for book titles, movie 
> > > > titles, play titles, song titles, etc?  Or would you just expect 
> > > > the script to search IMDB for anything marked up with ?

> > > 
> > > Again, I don't really know. I could see a use case for a "type" 
> > > attribute (as was suggested earlier in this thread), but that seems 
> > > like a slippery slope. Suggestions?
  
> > 
> > If we go with something like a TYPE attribute, I hope we can give it a 
> > better name. However, hiding semantics inside the value of an 
> > attribute is a poor markup design in humble opinion. (Although it also 
> > has some advantages.)

> 
> It's subclassing: the general is sufficient, the specific better. Many 
> markup languages use the design, and in this case, I think it's 
> necessary.
  


The class="" attribute can handle this case.


We appear to be talking about "lookups", "script", "semantics" and 
"markup" here rather than "style"; presumably to create custom link 
behaviours and assist in automated document processing. Perhaps there is 
an assumption that processing will only occur within the scope of the 
current page or site (and presumably therefore under the control of a 
single entity). However if  were to have a type then it's likely 
that the first systems to take advantage of it would be search-engines 
and catalogues. I feel that class should not be suggested as an 
alternative to a type attribute because it is completely unreliable for 
this usage, for reasons I won't repeat.


Using a type/rel/category attribute instead of class will assist in 
automated document processing and categorisation. It doesn't really 
matter whether a list of allowed types is defined or not since a 
search/directory crawler would probably deal with the uncommon or 
unsupported exceptions. But lumping the type of citation in with the 
class names used to style it is simply asking for trouble since it will 
also trigger any defined styles (probably unintentionally) and/or create 
nonsense categories like "book_class" in the processors' DB. I could 
imagine such a situation leading to the following catalogue output:


This article contains:
- 4 book citations
- 2 book_class citations
- 1 squiggly_underline citations

Hope that makes my position on this clearer. If I misunderstood 
somebodies comments then I apologise.


Shannon

Re: [whatwg] several messages about

[Ian Hickson]

On Tue, 15 Apr 2008, Shannon wrote:
> 
> It's alternative because it attempts to actually "classify" something 
> rather than generically label it. I agree that class should only do the 
> first and I do this with my own code but most designers do not. As far 
> as the web design world is concerned class serves no purpose except as a 
> JS/CSS hook. If you give class="book" or class="movie" special meaning 
> or behaviour then you run the risk of clashing with existing 
> stylesheets.
> 
> Right now the mainstream web is "misusing" class. If you suddenly make 
> class meaningful then some sites are going to get stung and not 
> necessarily at any fault of their own - since the intellectual 
> distinctions between "labels" and "classes" is of no concern to somebody 
> putting pretty borders on a page.

We're not talking about making class meaningful. I'm not sure I understand 
what you are arguing against at this point.

The proposal is just that authors should use class="" to distinguish the 
various ways they use  so that they can (e.g.) style them differently. 
Where is the spec unclear? I should rewrite it to avoid any ambiguities.

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

Re: [whatwg] several messages about proposals

[Mikko Rantalainen]

Ian Hickson wrote:
> On Tue, 24 Apr 2007, Elliotte Harold wrote:
>> It occurs to me that one of the most frequently used nits of 
>> pseudo-markup is to indicate sarcasm. For example,
>>
>> Yeah, George W. Bush has been such a great president.
>>
>> Should we perhaps formalize this? Is there any benefit to be achieved by 
>> adding an explicit sarcasm element to HTML?
> 
> [...]
> 
> I do not believe that starting down this slippery slope will get us enough 
> benefits to outweigh the costs involved. It isn't at all clear when we 
> would have to stop (just look at the proposals above, which quickly went 
> from just indicating sarcasm to pointing out other kinds of humour, other 
> emotions, etc).
> 
> I also believe that the rather limited success that analogous proposals 
> have enjoyed in print typography over the years should be a warning sign 
> for us to avoid introducing any explicit markup for this.
> 
> As has been noted, class keywords can be used for this purpose on a 
> site-by-site basis.

I agree that  or  or something equally specialized does
not deserve its own tag.

If there was a tag, it should be along the lines of  or
 or  which could then be classed as sarcasm
or joke or possible insult.

However, such element would probably go unused in any case. The only use
case I can come up with is that a search engine could warn the user
about the content in the search results. A search engine could also
ignore content inside such element because a machine is not expected to
understand the real meaning of such content and therefore it cannot be
successfully indexed automatically. Content authors probably do not care
about possible false positives of their content in the search engine
query results.

In cases where I've seen  or other such tags, they are meant to
be seen by the reader as literal tags (that is, the letters ""
are part of the content, not markup).

-- 
Mikko




signature.asc
Description: OpenPGP digital signature

Re: [whatwg] several messages about

[Shannon]

Ironically (given that you proposed using rel="" instead) as far as I know 
Google has never based anything on class values, but has used rel="" 
values (like rel="nofollow").


Which indicates to me that they were concerned enough about 
class="nofollow" to not use it. I personally think that "nofollow" is 
not a (rel)ationship and probably a misuse of that element. Anyway I'm 
not fixed on rel, it could be any name as long as it isn't type or 
class. It could be argued that conceptually "type", relationship" and 
"class" are three words that all mean exactly the same thing (the 
relationship of an object to its environment) but we have them all now 
and all apparently serving different purposes. Adding another attribute 
like category="movie" probably won't make things any easier.


For that reason I believe rel= for categories that "do" something and 
class= for categories that need styles/js is enough of a distinction as 
it helps keep designers and developers out of each others way.


As do I but that isn't relevant to the problem. If you feel that class 
should have a purpose other than it's widely used ones (styles and JS) 
then HTML5 must provide an alternative for these uses.



I don't understand why you think it's an alternative use. All of these 
uses are subclassing the element, the styling and scripting is then hookd 
on those subclasses.


  


It's alternative because it attempts to actually "classify" something 
rather than generically label it. I agree that class should only do the 
first and I do this with my own code but most designers do not. As far 
as the web design world is concerned class serves no purpose except as a 
JS/CSS hook. If you give class="book" or class="movie" special meaning 
or behaviour then you run the risk of clashing with existing stylesheets.


Right now the mainstream web is "misusing" class. If you suddenly make 
class meaningful then some sites are going to get stung and not 
necessarily at any fault of their own - since the intellectual 
distinctions between "labels" and "classes" is of no concern to somebody 
putting pretty borders on a page.


Shannon

Re: [whatwg] several messages about

[Ian Hickson]

On Tue, 15 Apr 2008, Shannon wrote:
> 
> > All of them. "class" isn't intended for styling, it's intended to 
> > subclass elements.
>
> Regardless of the intention of the class element it is NOT used in the 
> real world to subclass anything but styles and custom script. We may 
> wish otherwise but that is irrelevant. The value of class to me is:
> 
> * To get style information out of the content stream.
> * To allow the re-use and grouping of style information.
> * To provide alternate styles for printing, or user choice.
> * To identify related elements to javascript code.

Sure, and that's fine -- so long as the subclassing is done in a way that 
isn't specific to the desired presentation, there's no clash with the 
intent of the attribute.


> In a perfect world, yes. In reality the people involved may not even 
> work for the same company. I can see a situation arising where the 
> "meaning" of classes are being assigned by a company like Google for use 
> with their crawler but those classes are already be in use for 
> presentation purposes. How will the crawler know which uses are 
> intentional and which are not. How will the designer know which classes 
> are "reserved", when the system that will use them may not even exist 
> yet.

Ironically (given that you proposed using rel="" instead) as far as I know 
Google has never based anything on class values, but has used rel="" 
values (like rel="nofollow").


> As do I but that isn't relevant to the problem. If you feel that class 
> should have a purpose other than it's widely used ones (styles and JS) 
> then HTML5 must provide an alternative for these uses.

I don't understand why you think it's an alternative use. All of these 
uses are subclassing the element, the styling and scripting is then hookd 
on those subclasses.

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

Re: [whatwg] several messages about

[Shannon]

All of them. "class" isn't intended for styling, it's intended to subclass 
elements. 
Regardless of the intention of the class element it is NOT used in the 
real world to subclass anything but styles and custom script. We may 
wish otherwise but that is irrelevant. The value of class to me is:


* To get style information out of the content stream.
* To allow the re-use and grouping of style information.
* To provide alternate styles for printing, or user choice.
* To identify related elements to javascript code.

If class attribute was supposed to represent logical relationships or 
groupings in the information/content then it has already failed.


The subclassing can then be used for style, but using 
presentational classes (that is, classes that describe the desired 
presentation instead of the reason for that desire, the subclass of the 
element) misses the point.


For example, saying class="blue" with an associated .class { color: blue } 
will quickly become confusing if you decide those things should be red. It 
is in fact no better to use CSS that way than to use .


  
Agreed, I would personally never use class="blue". It was intended for 
the example only so the distinction I was making between "types" and 
"styles" was obvious. Designers are not used to thinking about these 
things. They'll use whatever Dreamweaver offers them regardless of the 
purpose for the information they are styling. Regardless of the 
enlightened opinion here designers will continue to do "what works" 
rather than what "makes sense". You won't change that with a spec (that 
most won't ever read). I've done a 2-year formal course in 
computer-aided design and these things were just not taught.




All the people involved in the developement of a site and its style sheets 
should of course agree on a set of class names.
  
In a perfect world, yes. In reality the people involved may not even 
work for the same company. I can see a situation arising where the 
"meaning" of classes are being assigned by a company like Google for use 
with their crawler but those classes are already be in use for 
presentation purposes. How will the crawler know which uses are 
intentional and which are not. How will the designer know which classes 
are "reserved", when the system that will use them may not even exist yet.
  
I strongly disagree with the characterisations of the class attribute 
in this example


As do I but that isn't relevant to the problem. If you feel that class 
should have a purpose other than it's widely used ones (styles and JS) 
then HTML5 must provide an alternative for these uses. I for one do not 
intend to use inline styles at all as I prefer keeping the design 
decisions outside of the HTML. That means you'll need to give me a list 
of all "meaningful" classes that might be used with  and other 
elements - but of course nobody can.


On the other hand except for rel="stylesheet" the rel attribute does not 
have these encumbrances and so deserves consideration.



Shannon

Re: [whatwg] several messages about

[Ian Hickson]

On Tue, 15 Apr 2008, Shannon wrote:
> 
> I've seen a few suggestions now that class be used as an identifying 
> attribute for purposes other than CSS. While this seems logical it 
> raises some issues for designers and implementers. Consider the 
> following:
> 
> The Neutronium Alchemist
> 
> In this example which of these classes is the type, and which serve only 
> as style?

All of them. "class" isn't intended for styling, it's intended to subclass 
elements. The subclassing can then be used for style, but using 
presentational classes (that is, classes that describe the desired 
presentation instead of the reason for that desire, the subclass of the 
element) misses the point.

For example, saying class="blue" with an associated .class { color: blue } 
will quickly become confusing if you decide those things should be red. It 
is in fact no better to use CSS that way than to use .


> There is also the issue to consider that website "developers" and 
> website "designers" are usually a totally different species. Designers 
> often have little understanding of how classes may be used in an 
> application. The potential is high that the designer will use 
> class="book" on a totally unrelated element which is bound to cause 
> visual problems if the application/developer is using the class as a 
> program element.

All the people involved in the developement of a site and its style sheets 
should of course agree on a set of class names.


> My proposed solution is to use the rel attribute which basically serves 
> this purpose already. It also has less potential for conflicts than the 
> type attribute since I have only ever seen rel used in the header 
> whereas type has existing meaning for input fields and script tags.
> 
> The Neutronium Alchemist

I strongly disagree with the characterisations of the class attribute in 
this example.

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

Re: [whatwg] several messages about

[Shannon]

If we go with something like a TYPE attribute, I hope we can give it a 
better name. However, hiding semantics inside the value of an 
attribute is a poor markup design in humble opinion. (Although it also 
has some advantages.)
  
It's subclassing: the general is sufficient, the specific better. Many 
markup languages use the design, and in this case, I think it's 
necessary.



The class="" attribute can handle this case.

  


I've seen a few suggestions now that class be used as an identifying 
attribute for purposes other than CSS. While this seems logical it 
raises some issues for designers and implementers. Consider the following:


The Neutronium Alchemist

In this example which of these classes is the type, and which serve only 
as style? A type or rel attribute is the better solution since it is 
generally understood to have a single value.  is an option but as 
others have pointed out it leads to potentially millions of new tags.


There is also the issue to consider that website "developers" and 
website "designers" are usually a totally different species. Designers 
often have little understanding of how classes may be used in an 
application. The potential is high that the designer will use 
class="book" on a totally unrelated element which is bound to cause 
visual problems if the application/developer is using the class as a 
program element.


My proposed solution is to use the rel attribute which basically serves 
this purpose already. It also has less potential for conflicts than  the 
type attribute since I have only ever seen rel used in the header 
whereas type has existing meaning for input fields and script tags.


The Neutronium Alchemist

Shannon

Re: [whatwg] several messages about

[Ian Hickson]

I seemed to have missed these when going through the  e-mails 
recently.

On Sat, 16 Apr 2005, John Lewis wrote:
>
> A way to mark up titles is something I've always wanted in HTML. 
> Currently,  is only appropriate for actual citations. I rarely 
> cite books, movies, etc.; I'm usually just talking about them.  is 
> worse. It's basically meaningless. The best I can do is  class="movie"> or something, and even then it's only appropriate for 
> titles that are italicized. Song names (and other minor works) are 
> generally written in quotation marks, not italicized.  
> is awful.

 has been extended to cover these cases now.


On Sun, 17 Apr 2005, Matthew Thomas wrote:
> 
> I think distinguishing between ordinary titles and real citations is 
> untenable, because there's not a workable dividing line. Consider these 
> examples:
> 
> 1.  My favorite book is The reality
> dysfunction by Peter F. Hamilton. It begins: Space
> outside the attack cruiser Beezling tore open
> in five places.
> 
> 3.  My favorite book is The reality
> dysfunction by Peter F. Hamilton.
> 
> Why should the title markup have suddenly changed? Do you expect the 
> editor of an online magazine's book reviews department, for example, to 
> have the presence of mind to change the title markup in the first 
> paragraph of a review if she happens to excise the last quote from 
> somewhere else in the review?

I agree. The spec is aligned with this thinking as well now.


On Sun, 17 Apr 2005, Anne van Kesteren wrote:
> 
> I think that would be acceptable. Although I wonder if CITE would still 
> be the right name... Can you still use CITE for persons in that case?
> 
>  John E. Simpson said in XPath and
>  XPointer: ...

Per the current spec, you explicitly can't.


On Sun, 17 Apr 2005, fantasai wrote:
> Anne van Kesteren wrote:
> > Ian Hickson wrote:
> > 
> > > > Then would you want different markup for book titles, movie 
> > > > titles, play titles, song titles, etc?  Or would you just expect 
> > > > the script to search IMDB for anything marked up with ?
> > > 
> > > Again, I don't really know. I could see a use case for a "type" 
> > > attribute (as was suggested earlier in this thread), but that seems 
> > > like a slippery slope. Suggestions?
> > 
> > If we go with something like a TYPE attribute, I hope we can give it a 
> > better name. However, hiding semantics inside the value of an 
> > attribute is a poor markup design in humble opinion. (Although it also 
> > has some advantages.)
> 
> It's subclassing: the general is sufficient, the specific better. Many 
> markup languages use the design, and in this case, I think it's 
> necessary.

The class="" attribute can handle this case.


On Sat, 7 May 2005, Henri Sivonen wrote:
> 
> I'd define  meaning a title of work (not a person and not limited 
> to quoted works).

The spec matches this now.

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

Re: [whatwg] several messages about proposals

[Ian Hickson]

On Tue, 24 Apr 2007, Elliotte Harold wrote:
>
> It occurs to me that one of the most frequently used nits of 
> pseudo-markup is to indicate sarcasm. For example,
> 
> Yeah, George W. Bush has been such a great president.
> 
> Should we perhaps formalize this? Is there any benefit to be achieved by 
> adding an explicit sarcasm element to HTML?

On Tue, 24 Apr 2007, Dan Brickley wrote:
> 
> Seems rather culturally specific. I found from living in Boston for a 
> while, that a British sense of humour often seems harsher and more 
> sarcastic to our gentle US cousins. So I wouldn't burn this into an 
> element name.

On Tue, 24 Apr 2007, Charles Iliya Krempeaux wrote:
> 
> An interesting proposal.
> 
> Some other things to consider is some of the other ways people mark up 
> sarcasm.
> 
> Some people mark it with a winking smiley.  As in...
> 
> ;-)
> 
> Or...
> 
> ;)
> 
> Although, this tends to be when a person is being sarcastic to be funny 
> or to tease someone.
> 
> I don't believe I've ever seen (or used myself) the winking smiley when 
> I'm being sarcastic AND I'm trying to be mean to the person, to in a 
> heated argument.  (I.e., using sarcasm to "make a point".)
> 
> Also... I've heard that Ethiopian Semitic languages and French actually 
> has a punctuation mark for sarcasm.

On Tue, 24 Apr 2007, Alexey Feldgendler wrote:
> 
> In Western typography, there is already a tradition to mark up irony 
> with quotation marks:
> 
> Yeah, George W. Bush has been such a “great” president.
> 
> I don't think a structural markup is required for something that has a 
> punctuation tradition, just like we don't introduce structural markup 
> for sentences (the punctuation, such as a full stop after the sentence, 
> suffices).
> 
> There was such an idea, but it hasn't been widely adopted. 
> http://en.wikipedia.org/wiki/Irony_mark

On Tue, 24 Apr 2007, Benjamin Hawkes-Lewis wrote:
>
> Marking up emotions and tones is an interesting idea, especially when 
> you consider the potential for talking browsers like Opera and Fire Vox. 
> But the general utility of marking up sarcasm is somewhat broader than 
> that for marking other emotions and tones, because sarcasm is 
> /especially/ likely to be misinterpreted. Hence the popularity of the 
> phrase: "I was being sarcastic". The crux of misunderstanding here is 
> that words are used in such a way as to undermine their surface meaning.
> 
> You can undermine your own words more or less explicitly. On the one 
> hand, you can give your audience no formal clues and depend entirely on 
> common notions shared with audience (say, about the excellence of US 
> presidents) for your disavowal to be detected, as with deadpan sarcasm 
> and a lot of satire. Alternatively, you can rely on various conventions 
> to modify the meaning of what is said, such as a nasal tone of voice, 
> "air quotes", and "scare quotes". For this more explicit disavowal, TEI 
> includes a fabulous  element:
> 
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-soCalled.html
> 
> I suspect that the implicit and explicit variations reflect authorial 
> intent and are not merely incidental. For that reason, I doubt markup 
> would be appropriate for the implicit form. But markup could certainly 
> be work well for the explicit variation.
> 
> Talking browsers and screen readers offer a good justification for using 
> markup in addition to punctuation for sarcasm. In Western languages at 
> least, it is only through markup that can they clearly distinguish 
> direct speech, quotation, and sarcasm, and assign them different voices. 
> Quotation punctuation is far more fluid and ambiguous than other 
> punctuation like commas, semicolons, question marks, full stops, and 
> exclamation marks. So Alexey's analogy with how we treat more reliable 
> punctuation is problematic.

On Tue, 24 Apr 2007, Elliotte Harold wrote:
> 
> There's an even stronger tradition to mark quotes with quotation marks, 
> and yet we have the q element.

On Tue, 24 Apr 2007, Brenton Strine wrote:
>
> So why not use the q element for irony as well, since a quote already 
> indicates both quotations and irony.

On Wed, 25 Apr 2007, Alexey Feldgendler wrote:
> 
> For the same reason why we don't want  used to mark up emphasis, 
> foreign words and defined terms (since italics are already used in 
> typography for all of this).

On Tue, 24 Apr 2007, Jon Barnett wrote:
>
> I think sarcasm is a good case for "class extensions"
> 
> http://wiki.whatwg.org/wiki/ClassExtensions
> 
> That could also apply to other tones of voice where context doesn't make 
> it obvious, such as irony, anger, suspicion, elation, and veiled 
> threats.

On Tue, 24 Apr 2007, ddailey wrote:
> 
> a. I rather like this sort of thing -- I wrote a note to the HTML WG a 
> month or so ago (in reflection on the   debate -- no I am 
> not trying to reopen that) about a variety of allied issues: graphemic, 
> pronunciation-related, and semantic 
> http://lists.w

Re: [whatwg] several messages about quotations

[fantasai]

Ian Hickson wrote:
Summary: I've made the spec require that any punctuation for  be 
included inside the element; I've added examples for .

> ...
How would you define CSS pseudo-elements for open and close quotes in 
such a way that they would be implementable and would not match 
apostrophes and would correctly differentiate between open and close 
quotes in languages that use the same character for opening and closing 
and in languages that invert the direction of guillemets compared to 
French?


I would introduce two pseudo-elements, ::quote-start and ::quote-end, 
which match one or more characters with the Quotation_Mark property (as 
per Unicode PropList) found at the start or end of an element, if such 
text is a direct child of the element (skipping White_Space characters).


I've started this idea down the path of the CSS working group.


Please send a message with your proposal to www-style for discussion and
CC www-international. (We use the wiki to track issues, not as a substitute
for mailing list discussion. Also, it would be important to have i18n people
involved since punctuation styles vary across languages and I'm not sure
Unicode's Quotation_Mark property is adequate.)

~fantasai

Re: [whatwg] several messages about

[Ian Hickson]

On Sun, 14 Nov 2004, Anne van Kesteren wrote:
>
> I was wondering if the WHATWG is going to redefine how NOSCRIPT[1] 
> works, since the current specification of it is quite difficult to 
> implement. Besides, I don't think it ever was implemented properly.
> 
> Also, brought to my attention by Bugzilla[2], how should content that 
> isn't rendered be treated?
> 
> [1]
> [2]

As far as I can tell, this is now all pretty much covered. If there are 
any specifics that I've missed, let me know.


On Sun, 29 May 2005, Kornel Lesinski wrote:
> 
> I see there is placeholder for  in WD, so here is my idea:
> 
> Remove  element from specification.
> 
> Since browsers support DHTML there is no need for specialized fallback 
> element. Authors can use any element and hide/replace it using scripts.
> 
> This is 100% backwards-compatible, works with all kinds of script types 
> and allows partial fallback for partially working scripts.

On Mon, 30 May 2005, Christian Biesinger wrote:
> 
> That does not work if the user disabled javascript, or if the user agent 
> does not support javascript (lynx, for example).

On Sun, 29 May 2005, theharmonyguy wrote:
>
> And not just Lynx - there are plenty of handheld/phone browsers that are 
> text-only or don't support all the latest features, including script.

On Mon, 30 May 2005, Anne van Kesteren wrote:
> 
> He's correct for a bit though. If you have the following element:
> 
>  
>   Foo bar, etc.
>  
> 
> You could easily remove that DIV from the flow using javascript. And 
> when javascript is disabled it would show up. Of course, compared to 
> NOSCRIPT this is suboptimal at best.

On Mon, 30 May 2005, Mikko Rantalainen wrote:
>
> I disagree. The  element is seldom used for anything else but 
> "this page requires javascript to work". The way I currently create web 
> applications is to first make it work without any scripting and finally 
> write scripts that tweak the final result. Often this tweaking requires 
> removing existing elements or adding a few new ones but it's all doable 
> in every browser I would script for anyway. The rest will get the 
> default noscript version of the page.
>
> If the script is going to add or remove at least one element in any case 
> there's very little extra work to remove the fallback behavior. If we 
> remove the noscript element, the DOM tree will be simpler and therefore 
> a little easier to script for the more complex cases.
> 
> I'd prefer suggesting that the noscript version is the default case (and 
> because it's the default there's no need for an extra element) and any 
> features or behavior added with scripting is optional extra that needs 
> to take care of everything required to "make it work".

On Mon, 30 May 2005, Henri Sivonen wrote:
> 
> I disagree.  does not tell which script features a script 
> needs. OTOH, the script itself can sniff for required DOM properties and 
> proceed to remove the fallback if all the required properties are 
> present.

On Mon, 30 May 2005, Kornel Lesinski wrote:
> 
> I don't see many real uses for . Mostly because  is 
> very primitive:
> 
> * doesn't work when script-aware browser lacks neccessary DOM or 
> XMLHTTPRequest support.
>
> * doesn't let you reuse its contents, so that's always "wasted" 
> bandwidth (browsers don't put contents of  in DOM tree)
>
> * doesn't work with multiple script types
> 
> Today most scripting solutions use progressive enchacement and don't 
> need  at all.
> 
> Decent dynamic menus work by transforming nested lists of links. 
> Maintaince of  alternative would be wasted effort.
> 
> sFIR and flashObject degrade nicely without .
> 
> Actually you don't have to look far - entire WebApps specification is 
> designed this way!

I've left  conforming in text/html, because while it's true that 
it isn't overly useful these days, it's not especially _harmful_ either, 
and we have to support it anyway, so removing it doesn't gain us much. 
Removing it _would_, however, introduce spurious and annoying conformance 
error messages in legacy content updated to use HTML5 features.

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

Re: [whatwg] several messages about quotations

[Ian Hickson]

Summary: I've made the spec require that any punctuation for  be 
included inside the element; I've added examples for .

On Wed, 10 Nov 2004, Thomas Scholz wrote:
> Ian Hickson schrieb:
> >
> > I sometimes want to take quotes and put them into floats with huge 
> > oversized quotemarks under the text at the top right and bottom left 
> > (it's quite a common effect in glossy magazines). This can't be done 
> > unless you can address the quotes directly somehow.
> 
> What about an element ?

Well, we have an element (), the problem is what to do with the 
quotation marks.


On Wed, 10 Nov 2004, Henri Sivonen wrote:
> On Nov 10, 2004, at 03:34, Ian Hickson wrote:
> > > 
> > > I agree with Henri, this is an authoring problem, not a styling a 
> > > problem.
> > 
> > But Henri agreed with me, saying that using markup for this was a bad 
> > idea.
> 
> What I agreed to was that using markup for smartening ASCII quotes was a 
> bad idea. I wouldn't mind using spans for the special case of floating 
> the quotation marks.
> 
> How would you define CSS pseudo-elements for open and close quotes in 
> such a way that they would be implementable and would not match 
> apostrophes and would correctly differentiate between open and close 
> quotes in languages that use the same character for opening and closing 
> and in languages that invert the direction of guillemets compared to 
> French?

I would introduce two pseudo-elements, ::quote-start and ::quote-end, 
which match one or more characters with the Quotation_Mark property (as 
per Unicode PropList) found at the start or end of an element, if such 
text is a direct child of the element (skipping White_Space characters).

I've started this idea down the path of the CSS working group.


On Wed, 10 Nov 2004, Max Romantschuk wrote:
> 
> I thought the issue on the table was the fact that the spec defines the 
> following: "Visual user agents must ensure that the content of the Q 
> element is rendered with delimiting quotation marks."
> 
> The problem arises with UAs which don't understand , and leaves out 
> the quotation marks. This results in the loss of the information that 
> the element content was a quote.

On Wed, 10 Nov 2004, Thomas Scholz wrote:
> 
> No, some UAs insert quotes, some don't. A new defined element  
> shouldn't require automagic quotes and leave this up to the author.

On Wed, 10 Nov 2004, Max Romantschuk wrote:
> 
> OK. I see your point. Even though this would esentially solve the 
> problem I would be hesitant to support such a solution. If two elements 
> mean the same thing on a semantic level and only differ in presentation 
> we're essentially returning to the HTML3 model of mixing content and 
> presentation.
> 
> I'm not claiming I have a better solution, but I feel we strive to 
> separate content from presentation and keep the semantic model as 
> unambiguous as possible.

I agree that introducing a new element just to solve the problem isn't 
really a good solution.


On Sat, 16 Apr 2005, fantasai wrote:
> John Lewis wrote:
> > I strongly believe quotation marks (for songs, etc.) should be written 
> > by the author in the document, not added with CSS.  is messy and 
> > hard to use.
> 
> I agree that  has problems, particularly with en-US style 
> punctuation. However, if the italics is going to be in the CSS, I think 
> the quotation marks should also be there.
> 
> I'd like to note also that citations in languages other than English -- 
> in Chinese, for example -- are probably done differently. (This is why 
> either all citation formatting should be the responsibility of the 
> author or none of it should be.)

I agree that the CSS should be able to override quotation punctuation.


On Wed, 13 Jul 2005, Bjoern Hoehrmann wrote:
> 
> What is proposed for XHTML 2.0 does not really work, I've discussed this 
> in .

Would it work if we required all punctuation to be included in the source 
(inside the  element), and provided the above-suggested pseudo-elements 
to deal with styling?

Did you ever receive a reply to that e-mail?


On Tue, 3 Apr 2007, Asbj�rn Ulsberg wrote:
> On Mon, 02 Apr 2007 23:52:48 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > > 
> > > Instead of enhancing the Q element, we should deprecate it and 
> > > replace it.
> > 
> > Replace it with what?
> 
> A new element,  for example.
>
> > What should we do with the existing content that uses ?
> 
> It will still be supported, but deprecated in favour of .
> 
> > This has been an open issue in the WHATWG for a while but nobody has 
> > come up with a particularily compelling solution -- either the 
> > solutions drop compatibility with existing content, or existing UAs, 
> > or require complex CSS features. (My own proposal falls in the latter 
> > camp; it makes  require quote marks around  elements 
> > (author-provided), then provides complex CSS that can select those 
> > quotes for replacement --

Re: [whatwg] several messages relating to the alt="" attribute

[Ian Hickson]

The HTMLWG's ISSUE-31 is "Should img without alt ever be conforming".

It isn't clear from this issue what exactly the problem with the current 
spec text is. The current text in the spec requires alt="" in all cases 
except when the page is generated in a manner where alternative text is 
not available, or when there is no possible way to provide text that is 
in any way a replacement for the image.

Two examples are given, namely a photo upload site, and a Rorschach 
inkblot test. In the former case, the image is generated automatically and 
the program simply does not have enough information to provide alternative 
text. In the latter case, _any_ description would miss the point of the 
test (which is to see what descriptions people come up with). The spec 
contains very strong wording requiring alternative text in all manner of 
possible situations, and encouraging it even in the aforementioned cases. 
I'm not sure what else we can do short of just making it non-conforming to 
create bulk-upload image hosting sites or write documents that contain 
inkblot tests.

If the issue's title is ever to be answered in the negative, it would be 
helpful for solutions to the two examples above to be provided.

I've closed the issue, to indicate that I have examined it in detail and 
come to a tentative conclusion. Further input from anyone, but in 
particular the PFWG, is welcome and encouraged; if anyone disagrees with 
this issue they are of course encouraged to reopen the issue in the issue 
database, preferably at the same time as providing further information to 
help answer the issues given above. :-)


Here are some answers to other issues raised on the topic:

On Thu, 6 Jan 2005, James Graham wrote:
> Matthew Thomas wrote:
> > 
> > For perhaps 95 percent of the images on the Web, the most appropriate 
> > alternate text is nothing at all. (In 2003 I did a survey of images in 
> > Wikipedia articles, where images aren't even used for decoration, and 
> > still found that alt="" would be the most sensible choice for 77 
> > percent of them.) So for that 95 percent, assuming that no alt is 
> > alt="" would improve the user experience.
> > 
> > Unfortunately, the other 5 percent would ruin the idea. When 
> > screenreaders are wading through inaccessibly-written pages, sometimes 
> > images are used for navigation (graphical menus, for example), so the 
> > user needs an indication that an image is there (whereupon they can 
> > guess its function by its URI). Assuming that all these images had 
> > alt="" would make such pages completely unnavigable.
> 
> Both this and the other point that Jim made (implied alt is hard to 
> debug) strongly suggest that alt should be optional, not implied. The 
> lack of an alt attribute would legitimize any inference about suitable 
> alternative text that the web browser wanted to perform. Therefore it 
> would remain best practice to explicitly declare alt="" where the image 
> is purely decorative. I expect many web developers would favor this 
> approach since the validator complaining about a lack of alt="" has been 
> perceived as unnecessary nannying and so the requirement has widely been 
> ignored. Making alt optional probably wouldn't damage accessibility as 
> much as might be thought because a) bad alt text is at least as bad as 
> missing alt text and b) there exist other tools that explicitly check 
> documents for accessibility which could flag missing alt attributes.

This is the reasoning behind the current wording of the specification.


On Thu, 6 Jan 2005, Andrew Kirkpatrick wrote:
> 
> Alt should be required on inputs of type=image, area elements, and perhaps
> on images within anchors (although images within an anchor that also
> contains text or another image with alt could be fine without alt also, so
> I'm not sure how to best handle that).

The form control issues (input type=image) are pending a result from the 
forms task force (I don't want to write that part of the spec only to find 
the whole thing has to be rewritten).

Omitted alt="" attributes only make sense (and are only, reluctantly, 
allowed) when the site serving the image simply has no idea what the image 
is, but knows that it is important.

One could easily imagine a situation where that is the case, but where the 
image is in a link. For example, any image on Flickr that doesn't have 
useful metadata falls into this category.

Thus I don't think we can make that requirement, as it would only lead to 
nonsense alt text or the concept of validity being ignored altogether.


> As a person who works in the area of accessibility, I'm inclined to 
> agree that alt doesn't really need to be required.  What is unusual is 
> that not only is this a solid idea theoretically, but the user agent 
> base supports it already.

That's good to know.


> Users can, and probably would continue to be able to, get their user 
> agent to voice all images without regard to the presence of alt if they 

Re: [whatwg] several messages

[Christoph Päper]

Ian Hickson (2008-03-23):

On Tue, 18 Mar 2008, Christoph Päper wrote:


a valid non-negative integer greater than zero.


Isn't that the description of a valid positive integer? If that  
term is

not used or defined yet, why not?


Because "positive" is confusing to people. Some people (including me)
think that 0 is positive.


Sure, but I thought "non-negative integer" was used to make it clear  
that zero was included. Thus for the (fewer) instances like this one,  
where zero is excluded, "positive integer" becomes available. You  
only need to say this once in 3.2.3., which is linked each time any  
way, and thereby improve readability. You could of course adopt the  
other definition of 'positive' instead.


Btw., there is a typo in the first sentence of 3.2.3.1.: the second  
'of' should be an 'or'.


Comparison of character string length:
  Zero  Count
-oo .. +oo   integer  ind.7  i
-oo .. -1negative integer ind.   16 -i
 non-positive integer less than zero  sep.   35! 
+i<0

 non-positive integer pos.   20!+i
-oo ..  0negative integer or zero ind.   24 -i|0
 non-positive integer sep.   20!+i
 non-positive integer or zero pos.   28! 
+i|0

  0 .. +oo   non-negative integer ind.   20!-i
 positive integer or zero sep.   24  
+i|0

 positive integer pos.   16 +i
  1 .. +oo   non-negative integer greater than zero   ind.   38!- 
i>0

 positive integer sep.   16 +i
 positive integer greater than zero   pos.*  34  
+i>0


pos.: zero is positive
sep.: zero has a separate state
ind.: independent of choice (based on "negative" never includes zero)

The second and third case (only negative integers) are virtually  
unneeded in HTML5.


ind. sep. pos.
  0  20   24   16
  1  38   16   34
  ø  29   20   25

On average character count supports non-positive zero (especially if  
combined with ind. wording), but if zero is usually included in  
HTML5, it may make sense to use "positive" in that way. The fully  
independent wording currently chosen is the worst alternative (by  
this criterion).


So either
  non-negative integer / positive integer
(instead of
  positive integer or zero / positive integer)
or
  positive integer / positive integer greater than zero,
but neither
  non-negative integer / non-negative integer greater than zero
nor
  non-negative integer / positive integer greater than zero.

One may consider these independet formulations, too:

-oo .. -1integer less than zero   ind.   22  i<0
-oo ..  0integer less than oneind.   21  i<1
  1 .. +oo   integer greater than zeroind.   25   
i>0


.oO(Much fuzz about "nothing".)

Why can |rowspan|, unlike |colspan|, be 0, but is then also  
normalised to 1?


It's not normalised to 1, is it? I don't understand.



It is not, I misinterpreted this sentence:

  Its default value, which must be used if parsing the attribute as a
  non-negative integer returns an error, is also 1.

Re: [whatwg] several messages about tables and related subjects

[Krzysztof Żelechowski]

Dnia 23-03-2008, N o godzinie 19:29 +, Ian Hickson pisze:
> Executive summary:
>  * header/id is in.
>  * summary="" is not in.
>  * axis="" is not in.
>  * the automatic header association algorithm has been expanded.
>  * a number of minor fixes and editorial edits were made.
> 
> For details, see revisions r1373 to r1396.
> 
> On Thu, 16 Aug 2007, Ben Boyle wrote:
> >
> > Look at the balance sheet (3rd table). It's like we have nested sections 
> > within the table. There's "net assets" that's broken down into "current 
> > assets", "non-current assets" and "liabilities", each either their own 
> > heading and totals (footer).
> > 
> > It would be interesting to investigate table markup that could support 
> > complex relationships within tables like this. It may be a bit esoteric, 
> > and can probably be handled through classes for those that need it. In 
> > either case it's very important we can clearly associate the headers 
> > with the right cells. I think it would be useful to be able to identity 
> > the "totals" (footers?) in each section too.
> 
> For simple cases like:
> 
>   WATER   FOOD
> CATS
>   male  871 12
>   female900 10
> TOTALS FOR CATS1771 22
> DOGS
>   male  871 12
>   female900 10
> TOTALS FOR DOGS1771 22
> TOTALS 3542 44
> 
> ...you can now easily get this effect by putting everything in the left 
> hand column into s, everything on the top row into s, and 
> everything on the bottom row into its own .
> 
> Does that work?

You are trying to map a cube onto a plane here.  
It will never work, 
except for the simplest cases the reader can easily imagine.
More formally, your table has two independent attributes enumerated:
table(species of {cats, dogs, all}, sex of {male, female, total}) 
and two dependent numerical ones:
= (water, food)
and should have the following four columns:

species sex water   food

An alternative would be to use tabs 
to present slices of the cube for different animals
--- but it is out of scope here, I presume.

> 
> 
> > I'm going to through a crazy idea into the mix and suggest that 
> > ,  and  may be useful within data tables for 
> > this very purpose.
> 
> I'm not clear on how that would work. (Especially considering backwards 
> compatibility and the CSS table model.)
> 
> 
> 


Aren't the two answers below contradictory?

> On Tue, 14 Nov 2006, Simon Pieters wrote:
> > 
> > Currently  requires at least one  element. [1] Why not zero 
> > or more? I think  is for  like  is for / (or a 
> >  group is for ).
> 
> Because if you have zero  elements, you actually have zero  
> elements, which is allowed.
> 
> 
> On Thu, 5 Apr 2007, Simon Pieters wrote:
> >
> > Why does  require one or more  elements, as opposed to zero 
> > or more?
> 
> Fixed.

> 
> Cheers,
Chris

Re: [whatwg] several messages about tables and related subjects

[Tab Atkins Jr.]

 >> TH and TD
>> * abbr (I think that's supported by screen readers, but need to verify)
>
>I don't really see that these attributes actually help anyone.

I don't have a screen reader to verify, but afaik abbr= is used to provide a
shortened form of the header when it is spoken aloud repeatedly.  Leaving it
out won't *hurt* anything, but the annoyance of hearing a large bit of
header repeated over and over again when the table is complex enough to
*need* a regular reminder would be enough, I think, for abbr= to be
considered to help people.

I use abbr= to this effect in my own tables.

~TJ

Re: [whatwg] several messages

[Ian Hickson]

On Sun, 23 Mar 2008, Paul Waring wrote:
> On 23/03/2008, Ian Hickson <[EMAIL PROTECTED]> wrote:
> >  > Isn't that the description of a valid positive integer? If that term is
> >  > not used or defined yet, why not?
> >
> >  Because "positive" is confusing to people. Some people (including me)
> >  think that 0 is positive.
>
> I'm fairly sure that there are also some people out there who argue that 
> you can have both -0 and +0, and these are two different numbers.

Sure, my point is just that we should avoid such confusion in the spec.

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

Re: [whatwg] several messages

[Paul Waring]

On 23/03/2008, Ian Hickson <[EMAIL PROTECTED]> wrote:
>  > Isn't that the description of a valid positive integer? If that term is
>  > not used or defined yet, why not?
>
>  Because "positive" is confusing to people. Some people (including me)
>  think that 0 is positive.

I'm fairly sure that there are also some people out there who argue
that you can have both -0 and +0, and these are two different numbers.

Paul

-- 
Paul Waring
http://www.pwaring.com

Re: [whatwg] several messages

[Ian Hickson]

On Tue, 18 Mar 2008, Christoph P�per wrote:
> >
> > +  Attributes common to td and th
> > elements
> > 
> > +  The td and th elements may have a  > +  title="attr-tdth-colspan">colspan content
> > +  attribute specified, whose value must be a valid non-negative
> > +  integer greater than zero.
> 
> Isn't that the description of a valid positive integer? If that term is 
> not used or defined yet, why not?

Because "positive" is confusing to people. Some people (including me) 
think that 0 is positive.

> > +  The td and th elements may also have a
> > +  rowspan content
> > +  attribute specified, whose value must be a valid non-negative
> > +  integer.
> 
> Why can |rowspan|, unlike |colspan|, be 0, but is then also normalised to 1?

It's not normalised to 1, is it? I don't understand.


On Wed, 19 Mar 2008, Michael Enright wrote:

> On Tue, Mar 18, 2008 at 2:23 PM, Christoph P�per
> <[EMAIL PROTECTED]> wrote:
> > > +  Attributes common to td and th
> >  > elements
> >  >
> >  > +  The td and th elements may have a  >  > +  title="attr-tdth-colspan">colspan content
> >  > +  attribute specified, whose value must be a valid non-negative
> >  > +  integer greater than zero.
> >
> >  Isn't that the description of a valid positive integer? If that term
> >  is not used or defined yet, why not?
> 
> The mathematical definitions of positive and negative integers exclude 
> zero, but the less-expert reader might not realize that zero is not 
> valid for colspan unless it is made explicit. "integer greater than 
> zero" would be one way to say it. Otherwise "positive non-zero integer"?

I think the current text is fine.

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

Re: [whatwg] several messages about the tree construction stage of HTML parsing

[Ian Hickson]

Executive summary:

Hoo boy did these e-mails end up with a lot of complicated changes -- a 
total of 38 different checkins. Some were editorial, but others were quite 
invasive changes. Here are the main ones:

 * Merged insertion modes and phases. Theoretically this didn't change 
   anything but as I'm sure I broke many things, please let me know what I 
   should fix. Note that I did the changes in steps, to make reviewing the 
   changes easier. (r1308-r1313)

 * Make a text node before an  start tag be a parse error. (r1314)

 * Strip spaces between  and  tags. (r1332)

 * Make  not get moved to . (r1328)

 * Fix the processing of  to work like . (r1320)

 * Make  parse like  in terms of leading newlines. (r1330)

 * Make spaces in  get reparented if there's been other content 
   that got reparented. (r1326)

 * Make  in  not get reparented unless 
   something else has been reparented. (r1331)

 * Make  and