agree they should be translatable

Why wouldn't this be done in the ARIA spec? Doing it here would mean that every ARIA host language has to list these each time. That's a layering violation at best, and an editorial mess at worst.

The ARIA spec does define these as the only two attributes that accept string values. The edit in question though, is in regards to the HTML @translate attribute, and how it controls the translatability of attributes in HTML. As such, these two ARIA attrs should be included in the list.

I don't understand why it makes sense to list ARIA attributes in the HTML spec. Should we also list all the ways SVG and MathML can introduce translatable text? How about other languages we don't know about that people will use with HTML?

(In reply to James Craig from comment #3)
> The ARIA spec does define these as the only two attributes that accept
> string values. The edit in question though, is in regards to the HTML
> @translate attribute,

It's not the HTML @translate attribute, it's the ITS2 @translate attribute:

  http://www.w3.org/TR/its20/#trans-datacat

As such, it's appropriate that that ARIA spec (instead of the HTML spec) should define which ARIA attributes are translatable. As Hixie points out in comment 4, it makes no more sense for the HTML spec to try to define which ARIA attributes are translatable than it does for the HTML spec to define which SVG or MathML attributes are translatable.

(In reply to Michael[tm] Smith from comment #5)
> (In reply to James Craig from comment #3)
> > The ARIA spec does define these as the only two attributes that accept
> > string values. The edit in question though, is in regards to the HTML
> > @translate attribute,
> 
> It's not the HTML @translate attribute, it's the ITS2 @translate attribute:
> 
>   http://www.w3.org/TR/its20/#trans-datacat

The bug references the HTML @translate attribute. 
http://www.w3.org/html/wg/drafts/html/master/dom.html#the-translate-attribute

If this HTML feature is pulling from the ITS2 spec, that should be clearly stated in the HTML spec.

> As such, it's appropriate that that ARIA spec (instead of the HTML spec)
> should define which ARIA attributes are translatable. As Hixie points out in
> comment 4, it makes no more sense for the HTML spec to try to define which
> ARIA attributes are translatable than it does for the HTML spec to define
> which SVG or MathML attributes are translatable.

I think it'd be appropriate to either mention those here or change the edit to mention that ~"The translatable attributes for ARIA, SVG, and MathML are (or should be) defined in their respective specifications." 

I'd be okay with removing the specific ARIA attrs if HTML would mention that there are additional translatable attributes, but that they are defined elsewhere. My concern is that there was previously no mention of these at all, so translation implementors would be likely to overlook them.

(In reply to Ian 'Hixie' Hickson from comment #4)
> I don't understand why it makes sense to list ARIA attributes in the HTML
> spec. Should we also list all the ways SVG and MathML can introduce
> translatable text? 

I think it's acceptable to acknowledge that these should/may be defined elsewhere.

> How about other languages we don't know about that people
> will use with HTML?

Other languages? I don't see the validity in this argument. Clearly the HTML spec knows about SVG, ARIA, and MathML because it makes specific mention of their use as being valid in HTML.

I definitely agree that it would make sense to say that other vocabularies might have translatable content too.

(In reply to James Craig from comment #7)
> Other languages? I don't see the validity in this argument.

How about, say, RDFa attributes. Or suppose someone defines a new language intended to be used with HTML, the way XForms was designed to work with XHTML2. They can define that it's valid to use their language with HTML, but there's no way we can know what attributes to list (since we don't know their language exists). So we can't give a comprehensive list.


> Clearly the HTML
> spec knows about SVG, ARIA, and MathML because it makes specific mention of
> their use as being valid in HTML.

Sure, but we shouldn't tie the evolution of these languages so tightly together that you can't progress one without the other — if we did that, there'd be no point them being separate languages, and we should just merge them. (Personally I'd be ok with that if we could find an editor with the bandwidth to do all those specs at once, but that's academic.) Since they are defined separately, we might as well benefit from that, and the way to benefit from that is to keep them orthogonal so that they can evolve separately.

(In reply to Ian 'Hixie' Hickson from comment #8)
> I definitely agree that it would make sense to say that other vocabularies
> might have translatable content too.

Do you agree that it makes sense to point to the specs that HTML knows about, because they can be used without namespaces in HTML?

PS. I also raised PFWG-ACTION-1267 to be more explicit in the ARIA spec about which attrs are translatable. (It's currenty just any that take string values.)

> Do you agree that it makes sense to point to the specs that HTML knows
> about, because they can be used without namespaces in HTML?

The only one that can be used without namespaces is ARIA, I think. (SVG and MathML are still namespaced in HTML, it's just that the namespacing is implicit in the text/html serialisaton.) But sure, we can mention explicit examples. I just don't want it to be authoritative, for the maintenance reasons mentioned above.

(In reply to Ian 'Hixie' Hickson from comment #10)
> > Do you agree that it makes sense to point to the specs that HTML knows
> > about, because they can be used without namespaces in HTML?
> 
> The only one that can be used without namespaces is ARIA, I think. (SVG and
> MathML are still namespaced in HTML, it's just that the namespacing is
> implicit in the text/html serialisaton.) But sure, we can mention explicit
> examples. I just don't want it to be authoritative, for the maintenance
> reasons mentioned above.

Steve Faulkner, if that works for you, will you propose a new edit that removes the explicit mention of the aria-label and aria-valuetext in the normative prose, and instead references the various latest TR specs for ARIA, SVG, and MathML?

You could list examples in an informative note, but I see Ian and Mike's points here that the normative list should not include attributes from these other specs.

(In reply to James Craig from comment #11)
> (In reply to Ian 'Hixie' Hickson from comment #10)
> > > Do you agree that it makes sense to point to the specs that HTML knows
> > > about, because they can be used without namespaces in HTML?
> > 
> > The only one that can be used without namespaces is ARIA, I think. (SVG and
> > MathML are still namespaced in HTML, it's just that the namespacing is
> > implicit in the text/html serialisaton.) But sure, we can mention explicit
> > examples. I just don't want it to be authoritative, for the maintenance
> > reasons mentioned above.
> 
> Steve Faulkner, if that works for you, will you propose a new edit that
> removes the explicit mention of the aria-label and aria-valuetext in the
> normative prose, and instead references the various latest TR specs for
> ARIA, SVG, and MathML?
> 
> You could list examples in an informative note, but I see Ian and Mike's
> points here that the normative list should not include attributes from these
> other specs.

Hi james, can do or can wait and see what hixies edit is and accept that if it is agreeable. We try to keep the HTML spec aligned with the whatwg spec where ever possible.

Checked in as WHATWG revision r8276.
Check-in comment: Mention that other specs may also list translatable attributes.
http://html5.org/tools/web-apps-tracker?from=8275&to=8276