[whatwg] Allowed characters in attribute names (was: Re: Stepsfor finding one or two numbers in a string)

[Kristof Zelechovski]

Why should I want to use a localized attribute name for the embed element?
I assume that the attribute named ‘smörgåsbord’ should necessarily
correspond to an internal property of the same name.  This would require a
localized compiler to compile the embedded object in the first place because
mixing natural languages like ‘switch(smörgåsbord)’ in source code looks bad
and makes the code chaotic and unreadable.
Of course, it can be done: it is possible to ‘#define välja switch’ and use
‘välja(smörgåsbord)’ instead---but that hack is not supported by modern
development languages like D and it need not work well with syntax-aware
code editors and static analyzers.

The following conditions must be met to make such a name appear in the
specification of an embed element:

* The development environment must be localized.
* The documentation must be translated into the developer's language.
* The developer must not understand a word of English and be extremely
unwilling or unable to learn some
or
* The attribute in question must denote a culture-specific notion that is
hardly expressible in English (one area I can imagine this may happen in is
law).
* The active element must be available to national public only.

Considering the conditions above, it turns out that your code sample is
highly whimsical and it uses a deprecated element that should be replaced
with an object element anyway.  So the standard is right: it need not be
supported and should not be required.

Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Simon Pieters
Sent: Wednesday, June 13, 2007 9:27 AM
To: Thomas Broyer; whatwg at whatwg.org
Subject: Re: [whatwg] Allowed characters in attribute names (was: Re:
Stepsfor finding one or two numbers in a string)

On Wed, 13 Jun 2007 09:11:31 +0200, Thomas Broyer <t.broyer at gmail.com>  
wrote:

> Why?
> Inconsistent maybe, but not incorrect.

Conformance checkers have to follow the parsing section. <embed  
smörgasbord="" src="foo"> is thus conforming. The #writing section is  
strictly speaking not necessary, it is merely a reverse engineered version  
of the parsing section taking the rest of the specification into account.  
In this case, it seems it didn't take the "any attribute" rule for <embed>  
into account.

> I'd rather change the #tokenisation section to generate more parse  
> errors.

Why? What if you want to pass a paramater to a plugin with non-ASCII  
characters using <embed>?

> Or maybe change the #creating section to drop such attributes, if we
> choose to follow the Safari/Opera/Firefox path.

Yeah, indeed.

-- 
Simon Pieters