[whatwg] Allowed characters in attribute names (was: Re: Stepsfor finding one or two numbers in a string)
giecrilj at stegny.2a.pl
Wed Jun 13 02:18:28 PDT 2007
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
* 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
* 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.
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>
> 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>
> I'd rather change the #tokenisation section to generate more parse
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.
More information about the whatwg