date:20120502

On Tue, May 1, 2012 at 11:09 PM, Aryeh Gregor a...@aryeh.name wrote:

 On Wed, May 2, 2012 at 8:00 AM, Ryosuke Niwa rn...@webkit.org wrote:
  Would it be useful to have placeholder content attribute on elements that
  are editable? (i.e. contenteditable=true).
 
  According to the original WebKit bug
  21286https://bugs.webkit.org/show_bug.cgi?id=21286,
  this may reduce the amount of code authors have to write.

 This sounds like a good idea to me.


Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.

e.g. Should it be treated as if there is a text node in the editable
element? Should we ignore things like br or collapsible spaces when
determining whether the element is empty or not?

- Ryosuke

Re: [whatwg] Should editable elements have placeholder attribute?

2012-05-02 Thread Aryeh Gregor

On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
 Great. I think the tricky part will be defining exactly how and when the
 placeholder is displayed.

 e.g. Should it be treated as if there is a text node in the editable
 element? Should we ignore things like br or collapsible spaces when
 determining whether the element is empty or not?

Currently the spec isn't clear about this for input, so I don't
think it needs to specify exactly for textarea or contenteditable
either.  It can be left as a UI decision.  As far as QoI goes, I think
you'd want to display it as long as there's no visible text or images
or things.  pbr/p should still display the placeholder, and
probably so should pfont color=redbr/font/p, etc.  As long
as there's no text (or img, etc.) that's visible to the user -- if
it *looks* empty, the placeholder should display.

But this should be up to the UA.

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

2012-05-02 Thread Evan Jones

On May 1, 2012, at 22:38 , Ashley Sheridan wrote:
 The Webkit method looks the better of the two with regards to how
 server-side languages might interpret it, but it would need work to
 ensure everything that should be escaped is, and that everything that is
 unescaped on the server should be and is done so correctly.

The problem is that currently I am unable to correctly round trip an uploaded 
file name. I would like users to upload a file, and be able to later download 
the file with the *exact same* file name. If you follow the specifications, 
this is not possible. Firefox is closer to the MIME RFCs (which specifies 
backslash quoting in quoted-strings), but apparently that will break IE6, 7, 
and 8:

https://bugs.webkit.org/show_bug.cgi?id=62107
http://java.net/jira/browse/JERSEY-759

Webkit's %-escaping behaviour is *not* part of the referenced MIME RFCs (which 
specifies either backslash quoting in quoted-strings, base64 encoding, or 
%-escaping in special filename*= arguments). Thus, if this is the right 
answer, it should be specified somewhere. I'm assuming that this needs to be 
in the HTML5 spec, since HTTP calls this the body of the the POST and 
declares that it is outside the HTTP specification.

Webkit's escaping is also flawed (see bug 62107 above). Files with that contain 
%-escapes (eg. my%22file.txt, admittedly very rare) will get mangled, because 
there is no difference between my%22file.txt and myfile.txt.

Currently, I need to detect the browser in order to figure out what kind of 
unescaping to apply to the file name, and even then in some cases I can't 
figure out what the right file name is. Webkit claims this is a specification 
bug, so I'm hoping someone here might tell me if this is the case, and if so 
where can I file bugs, create test cases, etc?

Evan

--
http://evanjones.ca/

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

2012-05-02 Thread Julian Reschke

On 2012-05-02 13:05, Evan Jones wrote:

On May 1, 2012, at 22:38 , Ashley Sheridan wrote:

The Webkit method looks the better of the two with regards to how
server-side languages might interpret it, but it would need work to
ensure everything that should be escaped is, and that everything that is
unescaped on the server should be and is done so correctly.

The problem is that currently I am unable to correctly round trip an uploaded
file name. I would like users to upload a file, and be able to later download the file
with the *exact same* file name. If you follow the specifications, this is not possible.
Firefox is closer to the MIME RFCs (which specifies backslash quoting in quoted-strings),
but apparently that will break IE6, 7, and 8:

https://bugs.webkit.org/show_bug.cgi?id=62107
http://java.net/jira/browse/JERSEY-759

Webkit's %-escaping behaviour is *not* part of the referenced MIME RFCs (which specifies either backslash
quoting in quoted-strings, base64 encoding, or %-escaping in special filename*= arguments). Thus,
if this is the right answer, it should be specified somewhere. I'm assuming that this needs to be
in the HTML5 spec, since HTTP calls this the body of the the POST and declares that it is outside
the HTTP specification.

Webkit's escaping is also flawed (see bug 62107 above). Files with that contain
%-escapes (eg. my%22file.txt, admittedly very rare) will get mangled, because there
is no difference between my%22file.txt and myfile.txt.

Currently, I need to detect the browser in order to figure out what kind of
unescaping to apply to the file name, and even then in some cases I can't
figure out what the right file name is. Webkit claims this is a specification
bug, so I'm hoping someone here might tell me if this is the case, and if so
where can I file bugs, create test cases, etc?

Evan

--
http://evanjones.ca/

I did spend a considerable amount of time with Content-Disposition, the
*response* header field (resulting in RFC 6266 and
http://greenbytes.de/tech/tc2231/).

However, this has little to do with the representation in form uploads.
If browser implementers want to try something new that will not affect
the old code paths, supporting the encoding defined in RFC 5987 might be
the right thing to do (yes, it's ugly, but it's unambiguous).

Best regards, Julian

[whatwg] Considering a lang- attribute prefix for machine translation and intelligibility

There has been some discussion on the w3c/whatwg mailing lists about how 
far we can mark up content with linguistic tags, such as marking word 
and/or sentence boundaries.


In my authoring of web apps, I often write a short manual into a hidden 
div, so that the vocabulary of my application can be processed by 
translation services such as Google translate. Having content in the DOM 
seems the most appropriate way to handle translation.


I'd like the group to consider the costs/benefits/alternatives to a 
lang- attribute.

Such as span lang-role=sentenceThis is a sentence./span

The data- and aria- attributes have worked out well. We may want to make 
room for one more.


Such a structure could be used to markup typical subject/object/verb and 
clause sections; it could also be used to markup poetic texts as well as 
defined meanings of content.


http://www.omegawiki.org/Expression:orange
This is an span lang-meaning=DefinedMeaning:orange_(5821)orange/span.
Now this, this is span 
lang-meaning=DefinedMeaning:orange_(5822)orange/span.


In most cases there's no need to define sentence boundary, meaning or 
otherwise. But, it'd sure be nice to have the ability to do so in a 
standard manner.


I'd recommend role, meaning and prosody/pronunciation as the primary 
targets. Character markup may be something to consider as it's come up 
in SVG (rotate) and in CSS before. Doing a span for each character is 
not practical, so we'd want a shorthand much as SVG has shorthand for 
rotate.


-Charles

Re: [whatwg] Should editable elements have placeholder attribute?

2012-05-02 Thread Ojan Vafai

On Wed, May 2, 2012 at 3:02 AM, Aryeh Gregor a...@aryeh.name wrote:

 On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
  Great. I think the tricky part will be defining exactly how and when the
  placeholder is displayed.
 
  e.g. Should it be treated as if there is a text node in the editable
  element? Should we ignore things like br or collapsible spaces when
  determining whether the element is empty or not?

 Currently the spec isn't clear about this for input, so I don't
 think it needs to specify exactly for textarea or contenteditable
 either.  It can be left as a UI decision.  As far as QoI goes, I think
 you'd want to display it as long as there's no visible text or images
 or things.  pbr/p should still display the placeholder, and
 probably so should pfont color=redbr/font/p, etc.  As long
 as there's no text (or img, etc.) that's visible to the user -- if
 it *looks* empty, the placeholder should display.

 But this should be up to the UA.


I'm OK with having when the placeholder is displayed be up to the UA. I can
see that being platform specific.

But, we should spec when content is eligible for showing a placeholder
(i.e. we should define what looks empty means). I don't see any benefit
in browsers behaving differently here. This part is not platform-specific.
It's just hard to figure out how to spec it.

Input is a different situation since the contents are plain text. It's very
straightforward. The placeholder is shown when the input is empty and not
focused.

I agree with everything else you say above in terms of cases that should
show the placeholder. :)

Re: [whatwg] Should editable elements have placeholder attribute?

On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai o...@chromium.org wrote:

 I'm OK with having when the placeholder is displayed be up to the UA. I
 can see that being platform specific.

 But, we should spec when content is eligible for showing a placeholder
 (i.e. we should define what looks empty means). I don't see any benefit
 in browsers behaving differently here. This part is not platform-specific.
 It's just hard to figure out how to spec it.


Maybe when element.innerText or element.textContent is empty?

- Ryosuke

Re: [whatwg] Should editable elements have placeholder attribute?


On 5/2/12 10:08 AM, Ryosuke Niwa wrote:

On Wed, May 2, 2012 at 10:06 AM, Ojan Vafaio...@chromium.org  wrote:


I'm OK with having when the placeholder is displayed be up to the UA. I
can see that being platform specific.

But, we should spec when content is eligible for showing a placeholder
(i.e. we should define what looks empty means). I don't see any benefit
in browsers behaving differently here. This part is not platform-specific.
It's just hard to figure out how to spec it.


Maybe when element.innerText or element.textContent is empty?


Is this something we might have a CSS selector for in the future?

I've previously asked about having CSS work a little more closely with 
innerHTML and textContent, but the only use case was for showing code in 
specs and tutorials, and it'd still need something like 
-webkit-text-select to work with generated content.


Such as:
code::before { content: html(); display: block; border: .1em solid black; }
codespanMy ihtml/i example/span/code

That'd also have a content: text(); which would use innerText. Both 
return strings.


So we'd have a css selector of something like:

ul[text()=] { content: attr(placeholder); }
ul contenteditable placeholder=testli/li/ul

-Charles

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

2012-05-02 Thread Evan Jones

On May 2, 2012, at 7:43 , Julian Reschke wrote:
 If browser implementers want to try something new that will not affect the 
 old code paths, supporting the encoding defined in RFC 5987 might be the 
 right thing to do (yes, it's ugly, but it's unambiguous).

It seems to me like that is a potential solution that could be evaluated. It 
would be nice to have both the HTTP response header and the POST form encoding 
be the same. However, a critical question is if the server software that parses 
the form headers would do the right thing if it sees both an ASCII fallback 
filename= and an escaped filename*= parameter in the Content-Disposition 
header. Without looking at any code, I suspect some will and some won't.

My conclusion: I would be willing to help with bugs, testing, test cases, 
looking at server code, etc related to this issue. However, I believe someone 
who is experienced with the technology and politics of web standards to really 
champion any change because I don't fully understand the processes or the 
issues. If I don't hear anything in a few days, I'll try filing some additional 
bugs with Webkit, Firefox, and the HTML5 spec and otherwise give up.

Thanks,

Evan Jones

--
http://evanjones.ca/

Re: [whatwg] Should editable elements have placeholder attribute?

On Wed, May 2, 2012 at 10:15 AM, Charles Pritchard ch...@jumis.com wrote:

 On 5/2/12 10:08 AM, Ryosuke Niwa wrote:

 On Wed, May 2, 2012 at 10:06 AM, Ojan Vafaio...@chromium.org  wrote:

  I'm OK with having when the placeholder is displayed be up to the UA. I
 can see that being platform specific.

 But, we should spec when content is eligible for showing a placeholder
 (i.e. we should define what looks empty means). I don't see any benefit
 in browsers behaving differently here. This part is not
 platform-specific.
 It's just hard to figure out how to spec it.

  Maybe when element.innerText or element.textContent is empty?


 Is this something we might have a CSS selector for in the future?


Sounds reasonable. We already have empty pseudo element but that won't
apply to div with just br.

So we'd have a css selector of something like:

 ul[text()=] { content: attr(placeholder); }


Such a CSS selector will be very expensive to implement. I don't think we
want something that generic. I think just adding a pseudo element that
matches a visibly empty element will be fine.

- Ryosuke

Re: [whatwg] Should editable elements have placeholder attribute?

2012-05-02 Thread Ojan Vafai

On Wed, May 2, 2012 at 10:08 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai o...@chromium.org wrote:

 I'm OK with having when the placeholder is displayed be up to the UA. I
 can see that being platform specific.

 But, we should spec when content is eligible for showing a placeholder
 (i.e. we should define what looks empty means). I don't see any benefit
 in browsers behaving differently here. This part is not platform-specific.
 It's just hard to figure out how to spec it.


 Maybe when element.innerText or element.textContent is empty?


textContent will strip a bunch of visible content (images, iframes, embeds,
etc.).

Another edge case to consider:
div contentEditable placeholder=foodiv
style=background-color:red;width:100px;height:100px/div/div

Re: [whatwg] Considering a lang- attribute prefix for machine translation and intelligibility

2012-05-02 Thread Tab Atkins Jr.

On Wed, May 2, 2012 at 9:59 AM, Charles Pritchard ch...@jumis.com wrote:
 There has been some discussion on the w3c/whatwg mailing lists about how far
 we can mark up content with linguistic tags, such as marking word and/or
 sentence boundaries.

 In my authoring of web apps, I often write a short manual into a hidden div,
 so that the vocabulary of my application can be processed by translation
 services such as Google translate. Having content in the DOM seems the most
 appropriate way to handle translation.

 I'd like the group to consider the costs/benefits/alternatives to a lang-
 attribute.
 Such as span lang-role=sentenceThis is a sentence./span

 The data- and aria- attributes have worked out well. We may want to make
 room for one more.

 Such a structure could be used to markup typical subject/object/verb and
 clause sections; it could also be used to markup poetic texts as well as
 defined meanings of content.

 http://www.omegawiki.org/Expression:orange
 This is an span lang-meaning=DefinedMeaning:orange_(5821)orange/span.
 Now this, this is span
 lang-meaning=DefinedMeaning:orange_(5822)orange/span.

 In most cases there's no need to define sentence boundary, meaning or
 otherwise. But, it'd sure be nice to have the ability to do so in a standard
 manner.

 I'd recommend role, meaning and prosody/pronunciation as the primary
 targets. Character markup may be something to consider as it's come up in
 SVG (rotate) and in CSS before. Doing a span for each character is not
 practical, so we'd want a shorthand much as SVG has shorthand for rotate.

Do you expect outside services to do anything useful with this
information?  If not, the data-* attributes seem appropriate.

If you do expect that, have you evaluated the existing mechanisms for
embedding custom data in the page and found them wanting? If so, how?

~TJ

Re: [whatwg] Should editable elements have placeholder attribute?

On Wed, May 2, 2012 at 10:49 AM, Ojan Vafai o...@chromium.org wrote:

 textContent will strip a bunch of visible content (images, iframes,
 embeds, etc.).

 Another edge case to consider:
 div contentEditable placeholder=foodiv
 style=background-color:red;width:100px;height:100px/div/div


Should that be considered as non-empty? If so, maybe we should define it as
either the content height or the content width being 0?

But what about divnbsp;/div? Should this also be considered as
non-empty?

- Ryosuke

Re: [whatwg] Considering a lang- attribute prefix for machine translation and intelligibility


On 5/2/12 10:50 AM, Tab Atkins Jr. wrote:

On Wed, May 2, 2012 at 9:59 AM, Charles Pritchardch...@jumis.com  wrote:

There has been some discussion on the w3c/whatwg mailing lists about how far
we can mark up content with linguistic tags, such as marking word and/or
sentence boundaries.

In my authoring of web apps, I often write a short manual into a hidden div,
so that the vocabulary of my application can be processed by translation
services such as Google translate. Having content in the DOM seems the most
appropriate way to handle translation.

I'd like the group to consider the costs/benefits/alternatives to a lang-
attribute.
Such asspan lang-role=sentenceThis is a sentence./span

The data- and aria- attributes have worked out well. We may want to make
room for one more.

Such a structure could be used to markup typical subject/object/verb and
clause sections; it could also be used to markup poetic texts as well as
defined meanings of content.

http://www.omegawiki.org/Expression:orange
This is anspan lang-meaning=DefinedMeaning:orange_(5821)orange/span.
Now this, this isspan
lang-meaning=DefinedMeaning:orange_(5822)orange/span.

In most cases there's no need to define sentence boundary, meaning or
otherwise. But, it'd sure be nice to have the ability to do so in a standard
manner.

I'd recommend role, meaning and prosody/pronunciation as the primary
targets. Character markup may be something to consider as it's come up in
SVG (rotate) and in CSS before. Doing a span for each character is not
practical, so we'd want a shorthand much as SVG has shorthand for rotate.

Do you expect outside services to do anything useful with this
information?  If not, the data-* attributes seem appropriate.


Yes, that's the primary reason. services such as Google translate.

If you do expect that, have you evaluated the existing mechanisms for
embedding custom data in the page and found them wanting? If so, how?


1. Google translate gets a little loose with some markup, to where the 
translated content may be placed outside the span tag.


Such as: div id=oneMy potato is spanhot/span/div.

2. Some words can be ambiguous to the point that even a human reader may 
not know what the meaning is. It'd be great to have a mechanism to 
disambiguate.


3. Speech markup is cool, I like it, but we can have something a little 
lighter or even have some interplay with prosody.

spanYou say spanpotato/span, I say spanpotato/span/span.
(poteitoe, potahtoe)

4. CSS markup has come up a few times for sentence, word and character 
boundaries. Language is not static, it is very much human, and enabling 
humans to markup their language is what HTML is all about.


I'll put some effort in later this week to dig up a few threads on the 
CSS requests.


5. Services should never touch data-*; I've had to put all my content 
into markup anyway. I've had to add id attributes so I can identify it 
when it's translated by the UA or other service. Since I've done all 
that work, it'd be really nice to have some more options to add in, such 
as disambiguation, part of speech and occasionally, pronunciation and 
translation suggestions.


-Charles

Re: [whatwg] Should editable elements have placeholder attribute?

2012-05-02 Thread David Young

On Wed, May 02, 2012 at 01:02:10PM +0300, Aryeh Gregor wrote:
 On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
  Great. I think the tricky part will be defining exactly how and when the
  placeholder is displayed.
 
  e.g. Should it be treated as if there is a text node in the editable
  element? Should we ignore things like br or collapsible spaces when
  determining whether the element is empty or not?
 
 Currently the spec isn't clear about this for input, so I don't
 think it needs to specify exactly for textarea or contenteditable
 either.  It can be left as a UI decision.  As far as QoI goes, I think
 you'd want to display it as long as there's no visible text or images
 or things.  pbr/p should still display the placeholder, and
 probably so should pfont color=redbr/font/p, etc.  As long
 as there's no text (or img, etc.) that's visible to the user -- if
 it *looks* empty, the placeholder should display.

I think that what you describe may hide state from the user (e.g., hides
the style that will apply) and limits which positions you can point at
with the mouse.

A better alternative is that pbr/p displays a character that holds
the position of the br and indicates its presence.  You could use a
return symbol, ⏎, or interpunct, ·, for the purpose.  In the example
pfont color=redbr/font/p, color that character red.

Dave

-- 
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

2012-05-02 Thread Julian Reschke


On 2012-05-02 19:26, Evan Jones wrote:

On May 2, 2012, at 7:43 , Julian Reschke wrote:

If browser implementers want to try something new that will not affect the old 
code paths, supporting the encoding defined in RFC 5987 might be the right 
thing to do (yes, it's ugly, but it's unambiguous).


It seems to me like that is a potential solution that could be evaluated. It would be 
nice to have both the HTTP response header and the POST form encoding be the same. 
However, a critical question is if the server software that parses the form headers would 
do the right thing if it sees both an ASCII fallback filename= and an escaped 
filename*= parameter in the Content-Disposition header. Without looking at any code, I 
suspect some will and some won't.


I'm pretty sure everybody will ignore filename* for now. Which means 
servers need to upgrade, but at least it would be an upgrade that 
doesn't break any existing behavior.



My conclusion: I would be willing to help with bugs, testing, test cases, 
looking at server code, etc related to this issue. However, I believe someone 
who is experienced with the technology and politics of web standards to really 
champion any change because I don't fully understand the processes or the 
issues. If I don't hear anything in a few days, I'll try filing some additional 
bugs with Webkit, Firefox, and the HTML5 spec and otherwise give up.
...


Sounds like a plan.

Best regards, Julian

Re: [whatwg] Should editable elements have placeholder attribute?

2012-05-02 Thread Alfonso Martínez de Lizarrondo

FWIW:

Recently I wrote such a plugin for CKEditor, it can be tested here:
http://alfonsoml.blogspot.com.es/2012/04/placeholder-text-in-ckeditor.html
I don't think that too many people request this feature, but that might be
simply because there are other bigger problems and they don't want to waste
the time with these details :-)

In my checks to see if the editor is empty I decided that empty means no
real content, only a paragraph or new line, and of course every browser
decided that clearing the content might mean a different default content
In the end this is the check that I'm using at the moment (I didn't perform
extensive tests, just enough to check that it seemed to work)

var value = data.replace( /[\n|\t]*/g, '' ).toLowerCase();
if ( !value || value == 'br' || value == 'pnbsp;br/p' || value ==
'pbr/p' || value == 'pnbsp;/p' )
return true;

Regards

2012/5/2 David Young dyo...@pobox.com

 On Wed, May 02, 2012 at 01:02:10PM +0300, Aryeh Gregor wrote:
  On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
   Great. I think the tricky part will be defining exactly how and when
 the
   placeholder is displayed.
  
   e.g. Should it be treated as if there is a text node in the editable
   element? Should we ignore things like br or collapsible spaces when
   determining whether the element is empty or not?
 
  Currently the spec isn't clear about this for input, so I don't
  think it needs to specify exactly for textarea or contenteditable
  either.  It can be left as a UI decision.  As far as QoI goes, I think
  you'd want to display it as long as there's no visible text or images
  or things.  pbr/p should still display the placeholder, and
  probably so should pfont color=redbr/font/p, etc.  As long
  as there's no text (or img, etc.) that's visible to the user -- if
  it *looks* empty, the placeholder should display.

 I think that what you describe may hide state from the user (e.g., hides
 the style that will apply) and limits which positions you can point at
 with the mouse.

 A better alternative is that pbr/p displays a character that holds
 the position of the br and indicates its presence.  You could use a
 return symbol, ⏎, or interpunct, ·, for the purpose.  In the example
 pfont color=redbr/font/p, color that character red.

 Dave

 --
 David Young
 dyo...@pobox.comUrbana, IL(217) 721-9981

Re: [whatwg] Considering a lang- attribute prefix for machine translation and intelligibility

2012-05-02 Thread Benjamin Hawkes-Lewis

On Wed, May 2, 2012 at 6:59 PM, Charles Pritchard ch...@jumis.com wrote:
 If you do expect that, have you evaluated the existing mechanisms for
 embedding custom data in the page and found them wanting? If so, how?


 1. Google translate gets a little loose with some markup, to where the
 translated content may be placed outside the span tag.

 Such as: div id=oneMy potato is spanhot/span/div.

 2. Some words can be ambiguous to the point that even a human reader may not
 know what the meaning is. It'd be great to have a mechanism to disambiguate.

 3. Speech markup is cool, I like it, but we can have something a little
 lighter or even have some interplay with prosody.
 spanYou say spanpotato/span, I say spanpotato/span/span.
 (poteitoe, potahtoe)

 4. CSS markup has come up a few times for sentence, word and character
 boundaries. Language is not static, it is very much human, and enabling
 humans to markup their language is what HTML is all about.

 I'll put some effort in later this week to dig up a few threads on the CSS
 requests.

 5. Services should never touch data-*; I've had to put all my content into
 markup anyway. I've had to add id attributes so I can identify it when it's
 translated by the UA or other service. Since I've done all that work, it'd
 be really nice to have some more options to add in, such as disambiguation,
 part of speech and occasionally, pronunciation and translation suggestions.

Sorry?

I don't get how *any* of these are problems with the existing
mechanisms for embedding custom data.

1. New features won't fix Google Translate bugs with existing
features, and it's more efficient for Google to fix Translate than for
the community to design, specify, and implement new features.

2, 3, and 4: Given an appropriate vocabulary, existing mechanisms can
encode unambiguous meanings, information about how text should be
spoken, and phrase and sentence boundaries. Unicode describes
character boundaries.

5. Tab isn't talking about data- here, but about all the various
mechanisms available to provide custom data for services to consume
(e.g. microdata, microformats, RDFa).

--
Benjamin Hawkes-Lewis

Re: [whatwg] Considering a lang- attribute prefix for machine translation and intelligibility


On 5/2/12 11:46 AM, Benjamin Hawkes-Lewis wrote:

On Wed, May 2, 2012 at 6:59 PM, Charles Pritchardch...@jumis.com  wrote:

If you do expect that, have you evaluated the existing mechanisms for
embedding custom data in the page and found them wanting? If so, how?

1. New features won't fix Google Translate bugs with existing
features, and it's more efficient for Google to fix Translate than for
the community to design, specify, and implement new features.


New features do allow services to coalesce around standards. That's what 
the standards are here for.

HTML5 just added a translate attribute.

Span does not in and of itself signify any semantic meaning. Doesn't 
that mean that Google Translate is operating correctly?



2, 3, and 4: Given an appropriate vocabulary, existing mechanisms can
encode unambiguous meanings, information about how text should be
spoken, and phrase and sentence boundaries. Unicode describes
character boundaries.


Boris brought up that the concept of letter could use some attention:
http://lists.w3.org/Archives/Public/www-style/2011Nov/0055.html

Yes, we have existing XML mechanisms for text should be spoken.

What existing mechanism do we have for disambiguation?



5. Tab isn't talking about data- here, but about all the various
mechanisms available to provide custom data for services to consume
(e.g. microdata, microformats, RDFa).


Tab asked directly why data- does not work

Yes, we have a lot of microformats, it's true. And RDFa.

They don't seem to be taking flight for these issues, and language 
translation seems like a high level issue appropriate for HTML. Again, 
look at the translate and lang attributes; those are baked into HTML.


I am approaching the lang- proposal as language agnostic, much as 
aria- is language agnostic.


This seems to be where we are currently:
img lang=es translate=no alt=No /

With alt having ARIA counterparts.

I'm suggesting a lang- with counterparts to translate, language code, 
and a vastly enhanced vocabulary, much as ARIA vastly enhanced the UI 
vocabulary. I think it could help in the long run.


-Charles

Re: [whatwg] Footer inside header

2012-05-02 Thread Benjamin Hawkes-Lewis

On Fri, Apr 27, 2012 at 3:41 AM, Andrés Sanhueza
peroyomasli...@gmail.com wrote:
 2012/4/26 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com:

 On Apr 26, 2012 5:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 according to the definition of
 footer, it appears that authorship information is most appropriate
 to put there.  But sometimes the byline is placed inside the header
 area, which is reasonably marked up with a header.

 Isn't that use case addressed by address?

 No. address is much narrower and indicated in the spec as such.
 Bylines can also contain the date or, in blog post, links to tags.

Good point.

Can you provide an example where you'd to put a footer *inside* a
header rather than after it like so:

 article
   header
 hgroup
   h1Headline/h1
   h2Subhead/h2
 /hgroup
   /header
   footer
 ptime datetime=2012-04-3030 April 2012/time/p
 paddressJohn Doe/address/p
 pTags:/p
 ul
   lia href=/tags/politicspolitics/a
   lia href=/tags/politicsenvironment/a
 /ul
   /footer
   pArticle body…/p
 /article

It's worth noting that the definition of header is broad enough to
allow byline, date, and tags (group of introductory or navigational
aids):

  
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element

So you could also do:

 article
   header
 hgroup
   h1Headline/h1
   h2Subhead/h2
 /hgroup
 ptime datetime=2012-04-3030 April 2012/time/p
 paddressJohn Doe/address/p
 pTags:/p
 ul
   lia href=/tags/politicspolitics/a
   lia href=/tags/politicsenvironment/a
 /ul
   /header
   pArticle body…/p
 /article

Personally, I think it might be easier to understand and provide user
agent behaviors if we to define header and footer as the header and
footer of sections, and then require:

   [start section]
   [zero or more aside elements]
   [zero or one header element]
   [other material]
   [zero or one footer element]
   [zero or more aside elements]
   [end section]

This way, if you hit a navigation key for footer you go to the end of
a section, like you'd expect.

Allowing aside before header or after footer is mostly a
concession to ad publishing.

In other words: define header and footer by their structural role
rather than their contents per se.

--
Benjamin Hawkes-Lewis

Re: [whatwg] Considering a lang- attribute prefix for machine translation and intelligibility

2012-05-02 Thread Benjamin Hawkes-Lewis

On Wed, May 2, 2012 at 8:01 PM, Charles Pritchard ch...@jumis.com wrote:
 1. New features won't fix Google Translate bugs with existing
 features, and it's more efficient for Google to fix Translate than for
 the community to design, specify, and implement new features.


 New features do allow services to coalesce around standards. That's what the
 standards are here for.

Existing mechanisms for embedding custom data are (being) standardized
and can make use of standardized vocabularies.

 HTML5 just added a translate attribute.

That doesn't describe a drawback with the using the existing mechanisms.

 Span does not in and of itself signify any semantic meaning. Doesn't that 
 mean that Google Translate is operating correctly?

No?

Moving text in or out of an element that mean[s] something on its
own (as the spec puts it) has potential to break things. But that's
also true, if less so, for an element that doesn't mean anything on
its own. There might be code (clientside JS, CSS selectors, XPointer
URIs, automation scripts, whatever) that depends on that text being
inside or outside that element at that position in the DOM.

That's not to say that Google Translate is operating incorrectly.
Translation inevitably changes the DOM. Text node contents change of
course. Because different languages may express the same ideas in
different orders, DOM nodes may need to be reordered. Because
different languages have different practices around compounding or
implying ideas with different numbers of words, what might be a
separate word in a separate element in one language might need to be
merged into another word outside the element, or vice versa. It's not
obvious that there is a correct behavior here, and I struggle to see
how the markup examples you proposed would help. (Perhaps you could
elaborate?) Researching and recommending authoring practices that make
translation less likely to break code might be a more immediately
fruitful line of enquiry, and might help inform the ultimate creation
of a vocabulary fit for purpose.

But more importantly, assuming such a vocabulary could be created,
this is not a reason why it could not be embedded using the existing
mechanisms. The HTML specification is not the only source of
standardized vocabulary on the web.

 2, 3, and 4: Given an appropriate vocabulary, existing mechanisms can
 encode unambiguous meanings, information about how text should be
 spoken, and phrase and sentence boundaries. Unicode describes
 character boundaries.

 Boris brought up that the concept of letter could use some attention:
 http://lists.w3.org/Archives/Public/www-style/2011Nov/0055.html

It's not clear to me that Boris has raised something not addressed by
Unicode, but in any case an appropriate vocabulary could be used for
letters too.

 Yes, we have existing XML mechanisms for text should be spoken.

 What existing mechanism do we have for disambiguation?

Any vocabulary you want to use with microdata, microformats, RDFa, etc.

If the vocabulary doesn't exist yet, create it and publish it as a spec.

 5. Tab isn't talking about data- here, but about all the various
 mechanisms available to provide custom data for services to consume
 (e.g. microdata, microformats, RDFa).


 Tab asked directly why data- does not work

He had two questions:

1. If you're only using the data yourself, why not data-?

2. If you want other people to use the data, why not the other
mechanisms for custom data embedding?

Your 5 points appeared to be in answer to his second question, because
you placed them as a list in response to it.

But never mind.

 Yes, we have a lot of microformats, it's true. And RDFa.

 They don't seem to be taking flight for these issues

I suspect that's because these are new mechanisms and markup is a
doomed solution to these problems at web scale.

Anyhow, given you're one of the few people asking to be able to encode
these details in markup, offering lack of usage as a reason for not
being able to use these mechanisms is circular.

 and language translation seems like a high level issue appropriate for HTML.

That's not a reason why you could not use the existing mechanisms.

Aside: just because a problem is important, does not mean that
introducing more markup features is an approach that will scale to
solve the problem across the web. More work on NLP would probably be a
better investment in this case.

 Again, look at the translate and lang attributes; those are baked into HTML.

That's not a reason why you could not use the existing mechanisms.

 I am approaching the lang- proposal as language agnostic, much as aria-
 is language agnostic.

 This seems to be where we are currently:
 img lang=es translate=no alt=No /

 With alt having ARIA counterparts.

 I'm suggesting a lang- with counterparts to translate, language code, and
 a vastly enhanced vocabulary, much as ARIA vastly enhanced the UI
 vocabulary. I think it could help in the long run.

That's just you choosing to use

Re: [whatwg] Form input element for value-unit pairs

On Sat, 5 Mar 2011, Christoph P�per wrote:

 Imagine a richt text processor done in HTML5. If you want to select the 
 font size (of a template or class, of course) how would you do it?
 
 Standalone word processors usually have a combo field that lets the user 
 enter a number [...] possibly adding controls for increasng and 
 decreasing [...] or they may allow the user to select one of the 
 predefined recommended or frequent values.

So far, input type=number handles these.


 In other places, software interface designers honor the variety of 
 absolute and relative (length) units by introducing a widget that bears 
 the number and the unit symbol, [...] Thus, would it make sense to add 
 another new type for the input element?

I think it would make sense to add something like this if we find that 
people do that kind of thing a lot. Currently you can get close using a 
type=number with a select; do sites do that?


On Wed, 9 Mar 2011, Diogo Resende wrote:

 This is just a numeric input. It has a unit, just like a monetary value, 
 but besides that it's just a number. Maybe a numeric input should have 
 some type of formatting to proper show the unit (prefix/suffix, decimals 
 places, decimal sep., ...).

On Mon, 14 Mar 2011, Christoph P�per wrote:
 
 A new type is probably not necessary, because a new attribute that is 
 called something like �unit� and is only valid in the �number� and 
 �range� states could be enough.

On Tue, 15 Mar 2011, Diogo Resende wrote:
 
 For me it would be great that a UA would implement an numberic input 
 with a visible but unchanged unit. Something like an input+span but 
 the span looking to be inside the input.
  
 [__12_pt_]
  ^-- cursor would not pass this point
 
 Extra:
 
 This is more interesting for other types of input, not necessarily 
 numeric, like IPv4, currencies, HH:MM, ..

That's an interesting idea, but it might be something we should leave to 
the Web Components work.

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

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Fri, 19 Nov 2010, Boris Zbarsky wrote:

 Given that SVG also has classes, it would make some sense to move 
 classList from HTMLElement to Element.  That way SVG, and any other 
 languages that define classes (XUL comes to mind, actually) can benefit 
 from it as well.
 
 Note that Gecko's current classList implementation lives on Element.

How do you handle the difference between SVG and HTML's className? I think 
it would be confusing to have classList work the same on both but not 
className.

(Currently, DOM Core and HTML both define classList; the former on Element 
and the latter on HTMLElement, because Anne and I disagree on what should 
happen here.)

For the spec's purposes my plan is to follow whatever implementations 
converge on. Currently WebKit does what the HTML/SVG specs say (.className 
is a string in HTML, an object in SVG, and .classList is HTML-specific), 
Gecko does a mixture of DOM Core and HTML/SVG say (.className is a string 
in HTML, an object in SVG, and .classList is on both but returns null in 
unknown namespaces), and Opera does a different mixture (.className is a 
string in HTML, an object in SVG, and .classList is on SVG and HTML nodes 
but not on nodes from unknown namespaces). (Didn't have other browsers 
available to test on this machine.)

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

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

On Fri, 28 Oct 2011, David H�s�ther wrote:

 It would be more useful if the DOMTokenList methods (contains, add, 
 remove, toggle) would take a space separated list of tokens. This is the 
 behavior most DOM libraries have when dealing with class names.
 
 So, when setting two classes, instead of
 
   ele.classList.add(hey);
   ele.classList.add(ho);
 
 you could do
 
 ele.classList.add(hey ho);
 
 Currently, the latter results in an INVALID_CHARACTER_ERR.
 
 The behavior of all methods should be obvious I guess.

This has now moved to DOM Core. If you still want this I recommend filing 
a bug on that spec.

   http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html


On Fri, 28 Oct 2011, Mike Taylor wrote:

 I would prefer if it returned the DOMTokenList, to enable chaining like:
 
foo.toggle('bar baz').remove('bat');

That makes for very hard to read code, IMHO. I much prefer:

   foo.toggle('bar');
   foo.remove('bat');

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

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

2012-05-02 Thread Rick Waldron

On Wed, May 2, 2012 at 6:13 PM, Ian Hickson i...@hixie.ch wrote:

 On Fri, 28 Oct 2011, David Håsäther wrote:
 
  It would be more useful if the DOMTokenList methods (contains, add,
  remove, toggle) would take a space separated list of tokens. This is the
  behavior most DOM libraries have when dealing with class names.
 
  So, when setting two classes, instead of
 
ele.classList.add(hey);
ele.classList.add(ho);
 
  you could do
 
  ele.classList.add(hey ho);
 
  Currently, the latter results in an INVALID_CHARACTER_ERR.
 
  The behavior of all methods should be obvious I guess.

 This has now moved to DOM Core. If you still want this I recommend filing
 a bug on that spec.

   http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html


 On Fri, 28 Oct 2011, Mike Taylor wrote:
 
  I would prefer if it returned the DOMTokenList, to enable chaining like:
 
 foo.toggle('bar baz').remove('bat');

 That makes for very hard to read code, IMHO. I much prefer:

   foo.toggle('bar');
   foo.remove('bat');


Mike's recommendation is the same API introduced by jQuery a few years ago
and since then, there have been many requests to expand the signature to
other jQuery APIs. The toggle('bar baz') is not a good example, it should
be illustrated with .add() and .remove():

foo.add(many class name strings);
foo.remove(many class name strings);


Adding 1 class at a time is a _very_ common pattern in real world web
development.

Rick




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

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

On Wed, 2 May 2012, Rick Waldron wrote:
 On Wed, May 2, 2012 at 6:13 PM, Ian Hickson i...@hixie.ch wrote:
  On Fri, 28 Oct 2011, David H�s�ther wrote:
  
   It would be more useful if the DOMTokenList methods (contains, add, 
   remove, toggle) would take a space separated list of tokens. This is 
   the behavior most DOM libraries have when dealing with class names.
  
   So, when setting two classes, instead of
  
 ele.classList.add(hey);
 ele.classList.add(ho);
  
   you could do
  
   ele.classList.add(hey ho);
  
   Currently, the latter results in an INVALID_CHARACTER_ERR.
  
   The behavior of all methods should be obvious I guess.
 
  This has now moved to DOM Core. If you still want this I recommend filing
  a bug on that spec.
 
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
 
 
  On Fri, 28 Oct 2011, Mike Taylor wrote:
  
   I would prefer if it returned the DOMTokenList, to enable chaining like:
  
  foo.toggle('bar baz').remove('bat');
 
  That makes for very hard to read code, IMHO. I much prefer:
 
foo.toggle('bar');
foo.remove('bat');
 
 Mike's recommendation is the same API introduced by jQuery a few years 
 ago and since then, there have been many requests to expand the 
 signature to other jQuery APIs. The toggle('bar baz') is not a good 
 example, it should be illustrated with .add() and .remove():

It was the chaining I was talking about with respect to Mike's example, 
not the multiple values.


 Adding 1 class at a time is a _very_ common pattern in real world web 
 development.

As mentioned above, this API has now moved to DOM Core. If you still want 
this I recommend filing a bug on that spec.

   http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

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

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

2012-05-02 Thread Anne van Kesteren


On Wed, 02 May 2012 15:41:07 -0700, Ian Hickson i...@hixie.ch wrote:

On Wed, 2 May 2012, Rick Waldron wrote:

Adding 1 class at a time is a _very_ common pattern in real world web
development.


As mentioned above, this API has now moved to DOM Core. If you still want
this I recommend filing a bug on that spec.

   http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html


We have one, thanks!

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13999


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

Re: [whatwg] restricted palette for input type=color

On Mon, 7 Mar 2011, Markus Ernst wrote:

 A content management or blog system for a corporate website allows to 
 set font and background colors. The designers define allowed color sets 
 the way that the corporate design guidelines are respected, and that the 
 text is always readable - e.g. three light color shades for backgrounds, 
 and two corporate colors and black for text.

You don't really need a colour picker for that... it's more a select 
than a colour picker. Or a series of radio buttons. If the presentation is 
more the concern, then we should probably rely on Web Components to solve 
the problem (styling a select with a new presentation, e.g.).


 While searching the list archives, I found a message from Ian Hickson: 
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017482.html 
 He suggested to use a select element for the purpose of a restricted 
 color set.

Good to know I'm consistent. :-D (I wrote the reply to the above paragraph 
before reading this paragraph!)


 Here's why I think it would be worth to reconsider this position:

 - A select element would display color names or values instead of 
 showing the colors, which does not make it a suitable UI for choosing 
 colors.

That's a presentation issue, though. We should let CSS and/or Web 
Components fix that; we shouldn't add new semantics for each desired 
presentation.


 - Restricting the color palette is actually almost as common a task, as 
 defining start and end dates of a date picker, and for sure more common 
 than defining a step in a date picker. Now we have the benefit of this 
 specialized color input element, it is a pity if it lacks customization 
 potential.

The step in the date picker is something that was basically supported just 
because we had to define what step= did anyway since we had it for 
numbers.

I don't disagree that it might make sense to limit the colour palette 
(e.g. only things with a brightness greater than 50%) for type=color. 
But that's a different use case, and a different feature, than the one 
given above.


 - The fact that most CMS do not have restricted color sets so far, does 
 not mean there is no demand for it, but rather shows the difficulty of 
 customizing tools such as TinyMCE. It is a hassle for CMS implementors 
 (who are often not highly skilled JS programmers), if they are expected 
 to respect corporate design guidelines.

I don't follow. Right now (before type=color is widely implemented) it's 
easier to provide a limited set of colours than all colours. Surely then 
we should see more CMSes have restricted colour sets if it's a matter of 
difficulty.


 - I assume that restricting a color set in an existing color picker is 
 not too hard to implement (of course I have no evidence for this 
 assumption).

That's, generally speaking, not a concern.


On Tue, 8 Mar 2011, Jukka K. Korpela wrote:
 
 I guess this would then have to be an attribute of datalist, making it 
 possible to restrict the set of available choices whenever a datalist is 
 used. How about exclusive? I would expect this to be reasonably easy 
 to implement and potentially useful for other input types, too.
 
 For example, consider a date picker. Quite often, whether trying to make 
 dates or selling flights, there is a known set of (non-consecutive) days 
 that are possible, so we would like to write, say,
 
 input type=date id=date name=date
   value=2011-04-01 list=datelist
 datalist id=datelist
option value=2011-04-01 label=April 1st
option value=2011-04-08 label=April 8th
option value=2011-04-09 label=April 9th
 /datalist
 
 This is currently conforming, though no browser seems to make use of the 
 datalist. A good implementation would open up a calendar for April, with 
 only days 1, 8, 9 selectable and day 1 highlighted. Many existing 
 applications use such interfaces, so there is apparent need for them.

It certainly exists. How common it is, I don't know. It's a subset of 
sites with date pickers, which itself is a pretty small subset of sites 
with forms, which is a subset of pages.

It's definitely something worth keeping in mind though as we look to 
where we might extend this feature. I haven't added it yet, because we're 
still not at a point where these form controls are very mature.

If anyone wants this particular feature prioritised, a good way to start 
would be documenting existing sites that have date pickers that do this 
kind of thing.


On Wed, 9 Mar 2011, Jukka K. Korpela wrote:
 
 Select is generic, like input type=text, as opposite to input 
 type=date, input type=color etc. So an implementation cannot 
 implement select in a content-aware way, like a date or color picker, 
 but it can (and hopefully will, but it is not required to) implement 
 e.g. input type=date with associated datalist as a date picker 
 with some dates highlighted and possibly (when the proposed new 
 exclusive attribute is used) all other dates grayed out.

This isn't a complete

Re: [whatwg] Can we make checkboxes readonly?

On Wed, 6 Apr 2011, Tab Atkins Jr. wrote:

 Currently, the spec disallows checkboxes from being made readonly.  Is 
 there some good reason for this?  If not, can we change it? Checkboxes 
 being readonly would be useful for the same reasons that text inputs 
 being readonly is.
 
 Radio buttons can't be readonly either, but they have the obvious 
 complication of being multiple elements.  We could define behavior for 
 them, of course.  One option is to take the @required route, and say 
 that if one radio button in a group is readonly, they all are.  We could 
 alternately say that a radio button being readonly means that that 
 specific input can't have its checkedness changed - if it's currently 
 unchecked, clicking on it won't check it; if it's currently checked, 
 clicking on a mutable radio button from the same group wouldn't change 
 the checkedness of either input.

What's the use case?

Are there any native platforms that have a concept of a read-only radio 
button or checkbox that isn't disabled?


On Wed, 6 Apr 2011, Jonas Sicking wrote:
 
 What are the use cases for readonly on input type=text? I would 
 imagine the use cases for checkbox isn't very different.

On Wed, 6 Apr 2011, Boris Zbarsky wrote:

 The primary one I've seen is to have a non-editable text input that the 
 user can still select-and-copy from.

Yeah. I'm not sure I would add readonly to text input controls if it 
didn't already exist.


On Wed, 6 Apr 2011, Tab Atkins Jr. wrote:
 
 An app may dynamically set inputs or groups of inputs to readonly based 
 on app state.  When you submit, though, it's impossible to tell (without 
 hacks) whether a checkbox was checked-but-disabled or just unchecked.  
 Handling the form data is *much* easier if you just get all the data, 
 regardless of whether, as a UI convenience, your app temporarily set 
 some of the inputs to readonly.

That's a use case for submitting disabled check boxes, not for read-only 
checkboxes, IMHO. (The same could be said for disabled text controls.)


On Sun, 1 May 2011, Maciej Stachowiak wrote:
 
 In native app UI, it's highly unusual to have a checkbox that is 
 read-only but not disabled. It would be extremely confusing for a 
 checkbox to have the enabled look but not actually be checkable. 
 Therefore, we should not encourage content authors to build UI that 
 looks like that.
 
 If you want to dynamically turn some inputs read-only but still submit 
 their values, then presumably you are using script and can add hidden 
 inputs to reflect that state. While this is inconvenient, I don't think 
 it is a good idea to create bad UI solely for convenience.
 
 Another possibility is to make read-only checkboxes look and act 
 disabled, with the only difference being whether the value is submitted 
 or not. I have no objection in principle to such a state, but:
 
 - readonly seems like a poor name for this state, since in the case of 
 text controls, readonly actually has different user-visible interaction 
 behavior from disabled, not just different submission rules.

 - The fact that older browsers wouldn't support this special state makes 
 it hard to adopt incrementally. disabled with an extra attribute saying 
 submit anyway would do a better job of degrading gracefully, but would 
 mean that for a while, authors have to do the hidden input trick as 
 fallback anyway.
 
 Given these things and the relative obscurity of the use case (UIs where 
 disabling and enabling controls follows a complex pattern are rare and 
 typically not good design anyway), I am not sure the feature is 
 worthwhile.

I agree with all the above.


On Thu, 7 Apr 2011, Randy wrote:

 Simple use case with existing car configurators:

 When a car feature / accessory is selected that requires another feat. / 
 access., I don't want customers to uncheck that feature, but still need 
 the submission of the required features.
 
 Or the Mootools library builder:

 Depending modules need to be selected and submitted in order to generate 
 the correct javascript file.
 
 Yes, you can re-add that logic server-side, but why would you want to 
 add that kind of logic twice.

You should always check the data on the server and not trust the client to 
get it right. The client could be completely untrusted.

But in any case, as Maciej says, you can store the data in a hidden input 
if you're doing things with script anyway. It's a two-line function to 
abstract out the logic of checking/unchecking a checkbox and updating a 
hidden input at the same time.


On Thu, 7 Apr 2011, David McMurray wrote:
 
 A lot of my work involves tables of data which can be navigated via a 
 highlighted cell much like a spreadsheet. Where some cells may be 
 readonly within the table itself, but perhaps editable through a popup 
 value picker opened by double clicking on the cell for example. In this 
 case the text input or checkbox would need to be readonly but still 
 provide a value through the form on

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

2012-05-02 Thread Rick Waldron



On Wednesday, May 2, 2012 at 6:41 PM, Ian Hickson wrote:  
 On Wed, 2 May 2012, Rick Waldron wrote:
  On Wed, May 2, 2012 at 6:13 PM, Ian Hickson i...@hixie.ch wrote:
   On Fri, 28 Oct 2011, David Håsäther wrote:
 
It would be more useful if the DOMTokenList methods (contains, add,  
remove, toggle) would take a space separated list of tokens. This is  
the behavior most DOM libraries have when dealing with class names.
 
So, when setting two classes, instead of
 
ele.classList.add(hey);
ele.classList.add(ho);
 
you could do
 
ele.classList.add(hey ho);
 
Currently, the latter results in an INVALID_CHARACTER_ERR.
 
The behavior of all methods should be obvious I guess.

   This has now moved to DOM Core. If you still want this I recommend filing
   a bug on that spec.

   http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html


   On Fri, 28 Oct 2011, Mike Taylor wrote:
 
I would prefer if it returned the DOMTokenList, to enable chaining like:
 
foo.toggle('bar baz').remove('bat');

   That makes for very hard to read code, IMHO. I much prefer:

   foo.toggle('bar');
   foo.remove('bat');

   
   
  Mike's recommendation is the same API introduced by jQuery a few years  
  ago and since then, there have been many requests to expand the  
  signature to other jQuery APIs. The toggle('bar baz') is not a good  
  example, it should be illustrated with .add() and .remove():
   
  
  
 It was the chaining I was talking about with respect to Mike's example,  
 not the multiple values.
  
  


Great, in both cases, what _you_ prefer is not what is desired based on most 
common patterns and use cases.

JS APIs like this should always return the object (constructed instance or not) 
and therefore chain implicitly.

I'll take this to DOM Core.

Rick

  
  
  Adding 1 class at a time is a _very_ common pattern in real world web  
  development.
   
  
  
 As mentioned above, this API has now moved to DOM Core. If you still want  
 this I recommend filing a bug on that spec.
  
 http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
  
 --  
 Ian Hickson U+1047E )\._.,--,'``. fL
 http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
 Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Can we make checkboxes readonly?

2012-05-02 Thread Glenn Maynard

On Wed, May 2, 2012 at 5:57 PM, Ian Hickson i...@hixie.ch wrote:

 On Wed, 6 Apr 2011, Jonas Sicking wrote:
  What are the use cases for readonly on input type=text? I would
  imagine the use cases for checkbox isn't very different.


(year+13mon)

It's useful if you want to have an isolated block of text that's easy to
copy-and-paste, without the selection spilling into adjacent text; you just
double-click the input, or focus it and hit ^A.  That isn't relevant for
checkboxes and radio buttons, of course.

-- 
Glenn Maynard

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list