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

[Rick Waldron]

On Wed, May 2, 2012 at 7:17 PM, Ian Hickson  wrote:

> On Wed, 2 May 2012, Rick Waldron wrote:
> >
> > JS APIs like this should always return the object (constructed instance
> > or not) and therefore chain implicitly.
>

Let me rephrase, I simply expect modern DOM APIs to return something useful.



>
> I understand that this is mostly a matter of taste in API design, but IMHO
> that's an anti-pattern.


If you're writing and designing specifications that will be implemented in
JavaScript, then you should design them _for_ JavaScript. Section 15 of
EcmaScript specifies more then enough "prior art" that supports my
statement above.


> It encourages poor style;


60% of the JavaScript written on the web disagrees.


> it discourages
> functional programming patterns, instead favouring state mutation
> patterns;


JavaScript is a multi-paradigm language, leave your design hangups at the
door.


it makes APIs harder to extend;


This is just outright false, considering JavaScript is probably the most
extendable and historically extended language at the API level.


> it makes APIs that do have
> useful return values inconsistent with other APIs;


elem.classList.add("foo") returns "undefined". That's hardly what I would
consider a "useful return value". Returning the element's classList
instance makes an incredible amount of rational sense.



> it is, in fact, a
> layering violation:

it attempts to shoehorn what should be a language

design feature into the API layer.
>

Much like the DOM and its weird C++ and Java influences.



>
> But I'll leave it up to the DOM guys to decide what to do for that
> interface. :-)
>

Is this group aiming to define APIs that developers will always paper over
with abstractions, guaranteeing all app code needs a good 50k just to
provide a decent API? Or shall we craft APIs that developers will actually
write code for?

Rick


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

[Cameron McCormack]

Rik Cabanier:

Who would do this in the current SVG world? As you say, (!elt.className)
would always return false...
Are you worried that new content won't work with an old viewer?


No that would actually continue to behave the same.  So I misspoke when 
I said things will "break" -- author expectations will break instead if 
they assume that that code which works on HTML elements would also work 
on SVG elements.


But maybe that's OK?

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

[Rik Cabanier]

On Wed, May 2, 2012 at 5:31 PM, Cameron McCormack  wrote:

> Rik Cabanier:
>
>  There was a discussion in the SVG WG about dropping the
>> SVGAnimatedxxx objects and have replace them with regular values. We
>> would need some tricks so we can change the DOM, but make it
>> backward compatible at the same time.
>>
>
> We have discussed this a few times, and I would desparately love for it
> to work, but I am unconvinced it will.  I can an imagine an author
> writing code like:
>
>  if (!elt.className) ...
>
> to test if a class has been set.  Even if we made the
> SVGElement.className SVGAnimatedString object one that stringifies to
> the class, add a [PutForwards] on to it so that assigning a string
> works, it would still break the above code, since the ! operator always
> returns false for an object.
>

Who would do this in the current SVG world? As you say, (!elt.className)
would always return false...
Are you worried that new content won't work with an old viewer?

Rik

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

[Cameron McCormack]

Rik Cabanier:

There was a discussion in the SVG WG about dropping the
SVGAnimatedxxx objects and have replace them with regular values. We
would need some tricks so we can change the DOM, but make it
backward compatible at the same time.


We have discussed this a few times, and I would desparately love for it
to work, but I am unconvinced it will.  I can an imagine an author
writing code like:

  if (!elt.className) ...

to test if a class has been set.  Even if we made the
SVGElement.className SVGAnimatedString object one that stringifies to
the class, add a [PutForwards] on to it so that assigning a string
works, it would still break the above code, since the ! operator always
returns false for an object.

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

[Rik Cabanier]

On Wed, May 2, 2012 at 5:03 PM, Boris Zbarsky  wrote:

> On 5/2/12 6:09 PM, Ian Hickson wrote:
>
>> 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?
>>
>
> Right now in Gecko it's on HTMLElement (and XULElement), with a domstring
> return value and on SVGStylable with a SVGAnimatedString return value.
>
> Longer term we could put it on Element and just have SVG shadow it, of
> course.
>
> I would love being able to drop the SVG-specific className, but I bet
> there's content


There was a discussion in the SVG WG about dropping the SVGAnimatedxxx
objects and have replace them with regular values.
We would need some tricks so we can change the DOM, but make it backward
compatible at the same time.


>
>
>  I think it would be confusing to have classList work the same on both but
>> not
>> className.
>>
>
> Why?  It doesn't seem to be any more confusing than the fact that
> className is present on both and just acts totally differently to start
> with...
>
>
>  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)
>>
>
> Thos last might be changing: see https://bugzilla.mozilla.org/**
> show_bug.cgi?id=741295
>
> -Boris
>

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

[Boris Zbarsky]

On 5/2/12 6:09 PM, Ian Hickson wrote:

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?


Right now in Gecko it's on HTMLElement (and XULElement), with a 
domstring return value and on SVGStylable with a SVGAnimatedString 
return value.


Longer term we could put it on Element and just have SVG shadow it, of 
course.


I would love being able to drop the SVG-specific className, but I bet 
there's content



I think it would be confusing to have classList work the same on both but not
className.


Why?  It doesn't seem to be any more confusing than the fact that 
className is present on both and just acts totally differently to start 
with...



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)


Thos last might be changing: see 
https://bugzilla.mozilla.org/show_bug.cgi?id=741295


-Boris

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

[Silvia Pfeiffer]

On Thu, May 3, 2012 at 2:59 AM, Charles Pritchard  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 This is a sentence.
>
> 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 orange.
> Now this, this is  lang-meaning="DefinedMeaning:orange_(5822)">orange.
>
> 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

Hi Charles,

In one of my companies, we've successfully used , @class and
@data-xxx attributes to support linguistic markup. See
http://www.eopas.org/transcripts/70 for an example (you will need to
agree to a research license checkbox to link through).

Here's a markup excerpt:







Maarik




maarik




mister




It supports multiple levels of linguistic semantic markup:
* phrase
* word
* morpheme
* gloss

If you wanted to make a standard for what levels should be marked up
in which way for linguistic data, you'd first have to get the
linguistic researchers to agree on the required feature-set. Then you
could standardise e.g. data-lang-xxx attributes - or even make up new
linguistic-xxx attributes .
http://www.whatwg.org/specs/web-apps/current-work/#extensibility
describes how to do that.

Hope this helps.

Cheers,
Silvia.

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

[Ian Hickson]

On Wed, 2 May 2012, Rick Waldron wrote:
> 
> JS APIs like this should always return the object (constructed instance 
> or not) and therefore chain implicitly.

I understand that this is mostly a matter of taste in API design, but IMHO 
that's an anti-pattern. It encourages poor style; it discourages 
functional programming patterns, instead favouring state mutation 
patterns; it makes APIs harder to extend; it makes APIs that do have 
useful return values inconsistent with other APIs; it is, in fact, a 
layering violation: it attempts to shoehorn what should be a language 
design feature into the API layer.

But I'll leave it up to the DOM guys to decide what to do for that 
interface. :-)

-- 
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?

[Glenn Maynard]

On Wed, May 2, 2012 at 5:57 PM, Ian Hickson  wrote:

> On Wed, 6 Apr 2011, Jonas Sicking wrote:
> > What are the use cases for readonly on ? 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

[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  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?

[Ian Hickson]

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 ? 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 rea

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

[Ian Hickson]

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  
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  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  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,
> 
>value="2011-04-01" list="datelist">
> 
>
>
>
> 
> 
> 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:
> 
>  is generic, like , as opposite to  type="date">,  etc. So an implementation cannot 
> implement  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.  with associated  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 picture. Sure, browsers won't automatically render a 
 in a manner specific to the data type of the values. But with 
some CSS and Web Component definitions, that can be changed. A  
with countries 

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

[Anne van Kesteren]

On Wed, 02 May 2012 15:41:07 -0700, Ian Hickson  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] DOMTokenList methods would be more useful with a space separated token list

[Ian Hickson]

On Wed, 2 May 2012, Rick Waldron wrote:
> On Wed, May 2, 2012 at 6:13 PM, Ian Hickson  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

[Rick Waldron]

On Wed, May 2, 2012 at 6:13 PM, Ian Hickson  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

[Ian Hickson]

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] classList should perhaps move from HTMLElement to Element

[Ian Hickson]

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] Form input element for value-unit pairs

[Ian Hickson]

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,  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 ; 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 + 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] Considering a lang- attribute prefix for machine translation and intelligibility

[Benjamin Hawkes-Lewis]

On Wed, May 2, 2012 at 8:01 PM, Charles Pritchard  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:
> 
>
> 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

Re: [whatwg] Footer inside header

[Benjamin Hawkes-Lewis]

On Fri, Apr 27, 2012 at 3:41 AM, Andrés Sanhueza
 wrote:
> 2012/4/26 Benjamin Hawkes-Lewis :
>>
>> On Apr 26, 2012 5:39 PM, "Tab Atkins Jr."  wrote:
>>>
>>> according to the definition of
>>> , 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 .
>>
>> Isn't that use case addressed by ?
>
> No.  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  *inside* a
 rather than after it like so:

 
   
 
   Headline
   Subhead
 
   
   
 30 April 2012
 John Doe
 Tags:
 
   politics
   environment
 
   
   Article body…
 

It's worth noting that the definition of  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:

 
   
 
   Headline
   Subhead
 
 30 April 2012
 John Doe
 Tags:
 
   politics
   environment
 
   
   Article body…
 

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  before  or after  is mostly a
concession to ad publishing.

In other words: define  and  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

[Charles Pritchard]

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

On Wed, May 2, 2012 at 6:59 PM, Charles Pritchard  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:


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] Considering a lang- attribute prefix for machine translation and intelligibility

[Benjamin Hawkes-Lewis]

On Wed, May 2, 2012 at 6:59 PM, Charles Pritchard  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: My potato is hot.
>
> 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.
> You say potato, I say potato.
> (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] Should editable elements have placeholder attribute?

[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 == '' || value == ' ' || value ==
'' || value == ' ' )
return true;

Regards

2012/5/2 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  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 "" or collapsible spaces when
> > > determining whether the element is empty or not?
> >
> > Currently the spec isn't clear about this for , so I don't
> > think it needs to specify exactly for  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.   should still display the placeholder, and
> > probably so should , etc.  As long
> > as there's no text (or , 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  displays a character that holds
> the position of the  and indicates its presence.  You could use a
> return symbol, ⏎, or interpunct, ·, for the purpose.  In the example
> , 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

[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?

[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  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 "" or collapsible spaces when
> > determining whether the element is empty or not?
> 
> Currently the spec isn't clear about this for , so I don't
> think it needs to specify exactly for  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.   should still display the placeholder, and
> probably so should , etc.  As long
> as there's no text (or , 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  displays a character that holds
the position of the  and indicates its presence.  You could use a
return symbol, ⏎, or interpunct, ·, for the purpose.  In the example
, 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

[Charles Pritchard]

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

On Wed, May 2, 2012 at 9:59 AM, Charles Pritchard  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 asThis is a sentence.

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 anorange.
Now this, this isorange.

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: My potato is hot.

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.

You say potato, I say potato.
(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?

[Ryosuke Niwa]

On Wed, May 2, 2012 at 10:49 AM, Ojan Vafai  wrote:

> textContent will strip a bunch of visible content (images, iframes,
> embeds, etc.).
>
> Another edge case to consider:
>  style="background-color:red;width:100px;height:100px">
>

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  ? Should this also be considered as
non-empty?

- Ryosuke

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

[Tab Atkins Jr.]

On Wed, May 2, 2012 at 9:59 AM, Charles Pritchard  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 This is a sentence.
>
> 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 orange.
> Now this, this is  lang-meaning="DefinedMeaning:orange_(5822)">orange.
>
> 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?

[Ojan Vafai]

On Wed, May 2, 2012 at 10:08 AM, Ryosuke Niwa  wrote:

> On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai  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:

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

[Ryosuke Niwa]

On Wed, May 2, 2012 at 10:15 AM, Charles Pritchard  wrote:

> On 5/2/12 10:08 AM, Ryosuke Niwa wrote:
>
>> On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai  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 .

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] multipart/form-data filename encoding: unicode and special characters

[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?

[Charles Pritchard]

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

On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai  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; }
My html example

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); }


-Charles

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

[Ryosuke Niwa]

On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai  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?

[Ojan Vafai]

On Wed, May 2, 2012 at 3:02 AM, Aryeh Gregor  wrote:

> On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa  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 "" or collapsible spaces when
> > determining whether the element is empty or not?
>
> Currently the spec isn't clear about this for , so I don't
> think it needs to specify exactly for  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.   should still display the placeholder, and
> probably so should , etc.  As long
> as there's no text (or , 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. :)

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

[Charles Pritchard]

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 This is a sentence.

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 orange.
Now this, this is lang-meaning="DefinedMeaning:orange_(5822)">orange.


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] multipart/form-data filename encoding: unicode and special characters

[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 my"file.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 
).


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

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

[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 my"file.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] Should editable elements have placeholder attribute?

[Aryeh Gregor]

On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa  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 "" or collapsible spaces when
> determining whether the element is empty or not?

Currently the spec isn't clear about this for , so I don't
think it needs to specify exactly for  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.   should still display the placeholder, and
probably so should , etc.  As long
as there's no text (or , etc.) that's visible to the user -- if
it *looks* empty, the placeholder should display.

But this should be up to the UA.