Re: [whatwg] deprecating

[Ian Hickson]

On Fri, 4 Sep 2015, henry.st...@bblfish.net wrote:
> 
> [...]

Since this topic is a potential security flaw in shipping software, I 
think it's probably unwise and irresponsible to be discussing the details 
in a public forum.

I'm sorry I sound like I keep trying to shut down this thread. I'm really 
not trying to do that specifically. This thread just keeps accidentally 
entering into the kinds of areas that we try to keep off the WHATWG list, 
to wit, non-technical arguments, arguments about other groups' 
specifications, arguments about implementors' plans and motives, details 
of unresolved security issues, and the like. For the record, other areas 
that we try to keep off this list include: discussions of the group's 
policies regarding what can be sent to the list, anything remotely 
ressembling harassment of any person or group of people, and generally 
anything that doesn't directly relate to technical changes to a WHATWG 
specification. If you have any questions about this please don't hesitate 
to e-mail me privately about them (you can even cc www-arch...@w3.org if 
you want a public record of the conversation).

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

Re: [whatwg] deprecating

[Ian Hickson]

On Wed, 2 Sep 2015, henry.st...@bblfish.net wrote:
> >
> > The spec just reflects implementations. The majority of 
> > implementations of  (by usage) have said they want to drop it,
> 
> There was a lot of pushback on those lists against dropping it, and no 
> clear arguments have been made for dropping keygen there.

That's debatable (see foolip's e-mail), but more to the point, it's 
irrelevant. We're not trying to reflect consensus here. We're trying to 
reflect reality. That's why the spec still has , but why it warns 
that browsers are planning on dropping it.


> > and the other major implementation has never supported it.
> 
> You mean IE? IE has always had something that did the same:
>
> https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
> 
> It is not idea, and it is easy to use both.

I'm not really sure what you're trying to argue here. Are you saying we 
should specify this API? Are other browsers planning on implementing it?


> To replace it with what? That is the problem that needs discussing and 
> not partially across twenty lists where the issues are only ever half 
> addressed.

Again, the point of the spec here is just to reflect reality; if browser 
vendors say they want to drop something, then we have to reflect that, 
even if they don't plan on replacing it with anything. Otherwise, our spec 
is just rather dry science fiction.

Having said that, it's my understanding that there are replacement APIs 
being developed. I'm not personally familiar with that work so I can't 
comment on it. Should the authors of a cryptography specification that 
browser vendors want to implement be interested in publishing their work 
through the WHATWG, I'm sure that could be arranged, and at that point 
this list would make for a very relevant place to discuss those 
technologies.


> Indeed: they seem to be working as one would expect where one thinking 
> that forces that don't like asymetric key cryptography to be widely 
> deployed were trying to remove that capability as far as possible. The 
> manner of doing this - by secret evidence, and pointers to closed non 
> deployed standards - seems to be very much the way of doing of 
> organisations that like to keep things secret and closed.

Asymetric key cryptography forms the basis of the entire Web's security 
system. It's pretty much the only possible way to have solid security in 
an environment where you don't trust the carrier. I doubt it's going 
anywhere anytime soon, unless we suddenly get a supply of securely- 
sharable one-time-pads...

The post foolip pointed to points out that  is actually rather 
insecure (e.g. using MD5). One could argue that _keeping_  is 
actually more harmful to asymetric-key cryptography than removing it...


> The case has been made that things should go the other way around: the 
> problems should be brought up, and then improvements or replacements 
> found. When those are found and are satisfactory ( as evaluated against 
> a wider set of values that take the whole web security into account ) 
> then one moves forward.

I certainly encourage people to follow such a pattern, but when they 
don't, we can't just ignore reality.

I encourage you to read our FAQ. The WHATWG has a much more pragmatic 
approach than other standards organisations you may be more familiar with.

   https://whatwg.org/faq

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

Re: [whatwg] deprecating

[henry.st...@bblfish.net]

> On 3 Sep 2015, at 20:21, Ian Hickson  wrote:
> 
> On Wed, 2 Sep 2015, henry.st...@bblfish.net wrote:
>>> 
>>> The spec just reflects implementations. The majority of 
>>> implementations of  (by usage) have said they want to drop it,
>> 
>> There was a lot of pushback on those lists against dropping it, and no 
>> clear arguments have been made for dropping keygen there.
> 
> That's debatable (see foolip's e-mail), but more to the point, it's 
> irrelevant. We're not trying to reflect consensus here. We're trying to 
> reflect reality. That's why the spec still has , but why it warns 
> that browsers are planning on dropping it.

yes, I see.

That is why it seems appropriate that the discussion moved
to the Technical Architecture Group (TAG) which can take a more 
global view of the situation.

>>> and the other major implementation has never supported it.
>> 
>> You mean IE? IE has always had something that did the same:
>> 
>> https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
>> 
>> It is not idea, and it is easy to use both.
> 
> I'm not really sure what you're trying to argue here. Are you saying we 
> should specify this API? Are other browsers planning on implementing it?

What I am saying is that all desktop browsers have implemented that 
functionality in one way or another for 15 years. So that it is misleaading
to make it look like it is only a minority that has been using it.

> 
> 
>> To replace it with what? That is the problem that needs discussing and 
>> not partially across twenty lists where the issues are only ever half 
>> addressed.
> 
> Again, the point of the spec here is just to reflect reality; if browser 
> vendors say they want to drop something, then we have to reflect that, 
> even if they don't plan on replacing it with anything. Otherwise, our spec 
> is just rather dry science fiction.

yes, what is needed therefore is a place where discussions making explicit
the reasons for this ( and other ) decision can be made, so that the larger
community of users of the technologies the browser vendors are implementing
can have a voice, and also like in any open source project to have a lot of
different eyes help work through the tangle of complexity in this field.

Clearly the  WHATWG does not see itself in the position to be such a forum, 
but is just an executor. 

> 
> Having said that, it's my understanding that there are replacement APIs 
> being developed. I'm not personally familiar with that work so I can't 
> comment on it. Should the authors of a cryptography specification that 
> browser vendors want to implement be interested in publishing their work 
> through the WHATWG, I'm sure that could be arranged, and at that point 
> this list would make for a very relevant place to discuss those 
> technologies.

What would be discussed here? As I see your point is that the WHATWG only 
publishes what has been implemented allready. 

I suppose I have been looking for a forum where discussions about standard
development was taking place, so that reasonable discussion could take place.
I see I was mistaken.

> 
> 
>> Indeed: they seem to be working as one would expect where one thinking 
>> that forces that don't like asymetric key cryptography to be widely 
>> deployed were trying to remove that capability as far as possible. The 
>> manner of doing this - by secret evidence, and pointers to closed non 
>> deployed standards - seems to be very much the way of doing of 
>> organisations that like to keep things secret and closed.
> 
> Asymetric key cryptography forms the basis of the entire Web's security 
> system. It's pretty much the only possible way to have solid security in 
> an environment where you don't trust the carrier. I doubt it's going 
> anywhere anytime soon, unless we suddenly get a supply of securely- 
> sharable one-time-pads...

yes, but it is not because the JS crypto API has methods to do asymmetric key
cryptography, that it is useable in the way needed for authentication etc...
The problem is that the JS crypto API have not developed a way to store 
the prive key in the browser without the JS from the same origin 
getting access to it. That is what is missing is a certain category of security
guarantees, which involve User Interface elements. 

From the discussions on the blink list it was clear that Ryan Sleevi thinks 
that it is a good enough answer for the security of private keys that they 
be place in HTML5 web storage. A lot of the decision to remove keygen and other
features depend on mistaken - or if I give him the benefit of the doubt, at 
best undocumented assumptions - of this sort.


> The post foolip pointed to points out that  is actually rather 
> insecure (e.g. using MD5). One could argue that _keeping_  is 
> actually more harmful to asymetric-key cryptography than removing it...

It can't be more insecure than storing the key in HTML5 web storage.
All keygen allows the browser to do is to sending the public 

Re: [whatwg] deprecating

[Ian Hickson]

On Thu, 3 Sep 2015, Melvin Carvalho wrote:
> >
> > The post foolip pointed to points out that  is actually rather 
> > insecure (e.g. using MD5). One could argue that _keeping_  is 
> > actually more harmful to asymetric-key cryptography than removing 
> > it...
> 
> Im not an expert here, but my understanding from reading some wikipedia 
> articles was that a preimage attack on md5 was 2^123.  If so, isnt that 
> pretty secure?  I asked on the blink thread why md5 was thought to be 
> insecure, but no one was able to answer, or point to a reference.  It 
> would be great to understand if there is a feasible attack here.

Wikipedia's article on MD5 is pretty comprehensive:

   https://en.wikipedia.org/wiki/MD5


> Looking at:
> 
> SignedPublicKeyAndChallenge ::= SEQUENCE {
> publicKeyAndChallenge PublicKeyAndChallenge
> ,
> signatureAlgorithm AlgorithmIdentifier,
> signature BIT STRING
> }
> 
> 
> http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-keygen-element

That's the W3C's fork of the specification. The relevant spec for this 
mailing list is:

   https://html.spec.whatwg.org/multipage/#the-keygen-element

I wouldn't use the W3C's fork for discussions here because the W3C version 
has many subtle differences and it can cause us great confusion when 
discussing these issues.


> There appears to be a field signatureAlgorithm.  Does that not suggest 
> that switching away from MD5 is future proofed?

In principle  itself could have new signature algorithms added. 
This of course wouldn't be backwards compatible (in that it wouldn't be 
supported by legacy UAs or legacy servers), so it would be no different 
than introducing an entirely new feature that didn't suffer from all the 
other problems that  suffers from.

This is somewhat academic, though. When there are no browser vendors 
supporting a particular feature, arguing about how it could be improved 
misses the point. That's why we added a warning to the spec.

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

Re: [whatwg] deprecating

[Ian Hickson]

On Thu, 3 Sep 2015, henry.st...@bblfish.net wrote:
> >>> 
> >>> and the other major implementation has never supported [].
> >> 
> >> You mean IE? IE has always had something that did the same:
> >> 
> >> https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
> >> 
> >> It is not idea, and it is easy to use both.
> > 
> > I'm not really sure what you're trying to argue here. Are you saying 
> > we should specify this API? Are other browsers planning on 
> > implementing it?
> 
> What I am saying is that all desktop browsers have implemented that 
> functionality in one way or another for 15 years. So that it is 
> misleaading to make it look like it is only a minority that has been 
> using it.

If you consider  and IE's Certificate Enrollment API to be 
equivalent, then I wouldn't worry about the deprecation warning regarding 
. I would fully expect a similar feature to be supported by the 
-supporting browsers long before  itself is removed. One 
might even hope that such a feature would be one developed in a standards 
environment with input from security expects and with with input from all 
vendors, and that it might therefore be more secure than  and 
actually implemented by all vendors, which would certainly be an 
improvement over the current situation.


> yes, what is needed therefore is a place where discussions making 
> explicit the reasons for this ( and other ) decision can be made, so 
> that the larger community of users of the technologies the browser 
> vendors are implementing can have a voice, and also like in any open 
> source project to have a lot of different eyes help work through the 
> tangle of complexity in this field.

If you have specific proposals for changes to the WHATWG specifications, 
then this mailing list would absolutely be a fine place for that.


> > Having said that, it's my understanding that there are replacement 
> > APIs being developed. I'm not personally familiar with that work so I 
> > can't comment on it. Should the authors of a cryptography 
> > specification that browser vendors want to implement be interested in 
> > publishing their work through the WHATWG, I'm sure that could be 
> > arranged, and at that point this list would make for a very relevant 
> > place to discuss those technologies.
> 
> What would be discussed here? As I see your point is that the WHATWG 
> only publishes what has been implemented already.

I encourage you to read our FAQ, which covers such matters in detail:

   https://whatwg.org/faq

Does that answer your question?


> yes, but it is not because the JS crypto API has methods to do 
> asymmetric key cryptography, that it is useable in the way needed for 
> authentication etc... The problem is that the JS crypto API have not 
> developed a way to store the prive key in the browser without the JS 
> from the same origin getting access to it. That is what is missing is a 
> certain category of security guarantees, which involve User Interface 
> elements.

I encourage you to bring such concerns up with the group(s) developing 
those APIs. As far as I'm aware, none of the WHATWG specs include JS 
crypto APIs. (And given that there are already groups working on such 
technologies, we wouldn't want to start a new spec for those technologies 
unless the browser vendors indicated that they weren't interested in the 
existing specs and wanted a new one.)


> From the discussions on the blink list it was clear that Ryan Sleevi 
> thinks that it is a good enough answer for the security of private keys 
> that they be place in HTML5 web storage. A lot of the decision to remove 
> keygen and other features depend on mistaken - or if I give him the 
> benefit of the doubt, at best undocumented assumptions - of this sort.

I recommend bringing this up with Ryan.

The only change that has been made to the WHATWG HTML spec is adding a 
note to the effect that the feature is likely to be removed. This is just 
a statement of fact, reflecting intents stated by browser vendors. It's 
not a value judgement and it's not a technical or normative change.

If you would like to discuss a technical change to the WHATWG HTML spec, 
then that would definitely be something that this list would be appricate 
for. To argue against the change that _has_ been made, though, you'd have 
to show that it wasn't accurate, which would presumably first mean 
convincing the browser vendors not to deprecate the feature in question.

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

Re: [whatwg] deprecating

[Oliver Hunt]

> On Sep 3, 2015, at 11:33 AM, Melvin Carvalho  wrote:
>> 
> 
> Im not an expert here, but my understanding from reading some wikipedia
> articles was that a preimage attack on md5 was 2^123.  

For a pre-image attack that’s true (or thereabouts), the real problem is that 
you can compute content to ensure a collision with a target hash. Essentially 
you can take some content, make the changes you want, and then mutate some 
other part of the data that isn’t important until you generate a collision.

This isn’t a theoretical attack, this was used to compromise/MiTM the windows 
update servers a few year ago (Flame attack i think?)

Anyhoo I can’t recall the time involved, but i suspect by now you can probably 
compute a collision in a few hours.

—Oliver
 

Re: [whatwg] deprecating

[Melvin Carvalho]

On 3 September 2015 at 20:21, Ian Hickson  wrote:

> On Wed, 2 Sep 2015, henry.st...@bblfish.net wrote:
> > >
> > > The spec just reflects implementations. The majority of
> > > implementations of  (by usage) have said they want to drop it,
> >
> > There was a lot of pushback on those lists against dropping it, and no
> > clear arguments have been made for dropping keygen there.
>
> That's debatable (see foolip's e-mail), but more to the point, it's
> irrelevant. We're not trying to reflect consensus here. We're trying to
> reflect reality. That's why the spec still has , but why it warns
> that browsers are planning on dropping it.
>
>
> > > and the other major implementation has never supported it.
> >
> > You mean IE? IE has always had something that did the same:
> >
> > https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
> >
> > It is not idea, and it is easy to use both.
>
> I'm not really sure what you're trying to argue here. Are you saying we
> should specify this API? Are other browsers planning on implementing it?
>
>
> > To replace it with what? That is the problem that needs discussing and
> > not partially across twenty lists where the issues are only ever half
> > addressed.
>
> Again, the point of the spec here is just to reflect reality; if browser
> vendors say they want to drop something, then we have to reflect that,
> even if they don't plan on replacing it with anything. Otherwise, our spec
> is just rather dry science fiction.
>
> Having said that, it's my understanding that there are replacement APIs
> being developed. I'm not personally familiar with that work so I can't
> comment on it. Should the authors of a cryptography specification that
> browser vendors want to implement be interested in publishing their work
> through the WHATWG, I'm sure that could be arranged, and at that point
> this list would make for a very relevant place to discuss those
> technologies.
>
>
> > Indeed: they seem to be working as one would expect where one thinking
> > that forces that don't like asymetric key cryptography to be widely
> > deployed were trying to remove that capability as far as possible. The
> > manner of doing this - by secret evidence, and pointers to closed non
> > deployed standards - seems to be very much the way of doing of
> > organisations that like to keep things secret and closed.
>
> Asymetric key cryptography forms the basis of the entire Web's security
> system. It's pretty much the only possible way to have solid security in
> an environment where you don't trust the carrier. I doubt it's going
> anywhere anytime soon, unless we suddenly get a supply of securely-
> sharable one-time-pads...
>
> The post foolip pointed to points out that  is actually rather
> insecure (e.g. using MD5). One could argue that _keeping_  is
> actually more harmful to asymetric-key cryptography than removing it...
>

Im not an expert here, but my understanding from reading some wikipedia
articles was that a preimage attack on md5 was 2^123.  If so, isnt that
pretty secure?  I asked on the blink thread why md5 was thought to be
insecure, but no one was able to answer, or point to a reference.  It would
be great to understand if there is a feasible attack here.

Looking at:

SignedPublicKeyAndChallenge ::= SEQUENCE {
publicKeyAndChallenge PublicKeyAndChallenge
,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}


http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-keygen-element

There appears to be a field signatureAlgorithm.  Does that not suggest that
switching away from MD5 is future proofed?

>
>
>
> > The case has been made that things should go the other way around: the
> > problems should be brought up, and then improvements or replacements
> > found. When those are found and are satisfactory ( as evaluated against
> > a wider set of values that take the whole web security into account )
> > then one moves forward.
>
> I certainly encourage people to follow such a pattern, but when they
> don't, we can't just ignore reality.
>
> I encourage you to read our FAQ. The WHATWG has a much more pragmatic
> approach than other standards organisations you may be more familiar with.
>
>https://whatwg.org/faq
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] deprecating

[Melvin Carvalho]

On 3 September 2015 at 21:27, Ian Hickson  wrote:

> On Thu, 3 Sep 2015, Melvin Carvalho wrote:
> > >
> > > The post foolip pointed to points out that  is actually rather
> > > insecure (e.g. using MD5). One could argue that _keeping_  is
> > > actually more harmful to asymetric-key cryptography than removing
> > > it...
> >
> > Im not an expert here, but my understanding from reading some wikipedia
> > articles was that a preimage attack on md5 was 2^123.  If so, isnt that
> > pretty secure?  I asked on the blink thread why md5 was thought to be
> > insecure, but no one was able to answer, or point to a reference.  It
> > would be great to understand if there is a feasible attack here.
>
> Wikipedia's article on MD5 is pretty comprehensive:
>
>https://en.wikipedia.org/wiki/MD5


Thanks, I have tried to work out the attack from this article, but still
dont see how it applies to KEYGEN.

The private key never leaves the browser.

All that is (optionally) sent to a server is a signed challenge.  Using the
randomchars field I think was designed to prevent the kind of attack that I
think people are imagining.  As yet, no one has actually *said* what the
attack is.  I am assuming people are trying to derive a private key from a
signature and public key.

It strikes me that this is impossible, even if dealing with a malicious
server.  But I'd like to understand if this is not the case.


>
>
>
> > Looking at:
> >
> > SignedPublicKeyAndChallenge ::= SEQUENCE {
> > publicKeyAndChallenge PublicKeyAndChallenge
> > <
> http://www.w3.org/html/wg/drafts/html/master/semantics.html#publickeyandchallenge
> >,
> > signatureAlgorithm AlgorithmIdentifier,
> > signature BIT STRING
> > }
> >
> >
> >
> http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-keygen-element
>
> That's the W3C's fork of the specification. The relevant spec for this
> mailing list is:
>
>https://html.spec.whatwg.org/multipage/#the-keygen-element
>
> I wouldn't use the W3C's fork for discussions here because the W3C version
> has many subtle differences and it can cause us great confusion when
> discussing these issues.
>

OK, thanks!


>
>
> > There appears to be a field signatureAlgorithm.  Does that not suggest
> > that switching away from MD5 is future proofed?
>
> In principle  itself could have new signature algorithms added.
> This of course wouldn't be backwards compatible (in that it wouldn't be
> supported by legacy UAs or legacy servers), so it would be no different
> than introducing an entirely new feature that didn't suffer from all the
> other problems that  suffers from.
>
> This is somewhat academic, though. When there are no browser vendors
> supporting a particular feature, arguing about how it could be improved
> misses the point. That's why we added a warning to the spec.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] deprecating

[henry.st...@bblfish.net]

> On 3 Sep 2015, at 21:44, Ian Hickson  wrote:
> 
> On Thu, 3 Sep 2015, henry.st...@bblfish.net wrote:
> 
> and the other major implementation has never supported [].
 
 You mean IE? IE has always had something that did the same:
 
 https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
 
 It is not idea, and it is easy to use both.
>>> 
>>> I'm not really sure what you're trying to argue here. Are you saying 
>>> we should specify this API? Are other browsers planning on 
>>> implementing it?
>> 
>> What I am saying is that all desktop browsers have implemented that 
>> functionality in one way or another for 15 years. So that it is 
>> misleaading to make it look like it is only a minority that has been 
>> using it.
> 
> If you consider  and IE's Certificate Enrollment API to be 
> equivalent, then I wouldn't worry about the deprecation warning regarding 
> . I would fully expect a similar feature to be supported by the 
> -supporting browsers long before  itself is removed. One 
> might even hope that such a feature would be one developed in a standards 
> environment with input from security expects and with with input from all 
> vendors, and that it might therefore be more secure than  and 
> actually implemented by all vendors, which would certainly be an 
> improvement over the current situation.

Its a bit optimistic especially in the security area to think that if you remove
a security component it is going to magically re-appear. 

Anyway, let's leave that discussion to the TAG.

Still I think I'll chime in with Melvin and the point I made earlier
that it would be good to have more details on what the security issues
with keygen are. At the minimum it may be worth explaining this in the
WHATWG spec.

As I wrote in the previous mail in response to your point:

>> 
>> The post foolip pointed to points out that  is actually rather 
>> insecure (e.g. using MD5). One could argue that _keeping_  is 
>> actually more harmful to asymetric-key cryptography than removing it...
> 
> It can't be more insecure than storing the key in HTML5 web storage.
> All keygen allows the browser to do is to sending the public key ( hopefully 
> over TLS ) to the server which can then send you back a certificate. Since 
> the private key does not leave the user agent there is not much that can go 
> wrong. After all it is a Public Key that then in any case will be published! T
> hats the whole point of asymetric key cryptography! :-)

So yes, what is the attack vector here?

Henry



Social Web Architect
http://bblfish.net/

Re: [whatwg] deprecating

[henry.st...@bblfish.net]

> On 2 Sep 2015, at 14:56, Philip Jägenstedt  wrote:
> 
> On Wed, Sep 2, 2015 at 1:00 PM, henry.st...@bblfish.net
>  wrote:
>> 
>>> On 1 Sep 2015, at 19:56, Ian Hickson  wrote:
>>> 
>>> As far as I can tell, therefore, things here are working exactly as one
>>> should expect.
>> 
>> Indeed: they seem to be working as one would expect where one thinking that 
>> forces
>> that don't like asymetric key cryptography to be widely deployed were trying 
>> to
>> remove that capability as far as possible. The manner of doing this - by 
>> secret
>> evidence, and pointers to closed non deployed standards - seems to be very 
>> much
>> the way of doing of organisations that like to keep things secret and closed.
> 
> This is borderline conspiratorial and is really not helpful. The first
> message in the blink-dev thread [1] nicely summarizes the motivation.
> If you distrust that and think that something more sinister is going
> on, fine, but that's no way to have a fruitful discussion.
> 
> Lots of things have been removed from specs and implementations
> following roughly the same "process", which is that some implementor
> realizes that they'd like to remove something, check if other
> implementors are on board, and then ask to have the spec changed.
> 
> [1] 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

I sent a more detailed e-mail to the TAG where I think the discussion has per 
force moved to 
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0010.html


> 
> Philip

Social Web Architect
http://bblfish.net/

Re: [whatwg] deprecating

[henry.st...@bblfish.net]

> On 1 Sep 2015, at 19:56, Ian Hickson  wrote:
> 
> On Tue, 1 Sep 2015, henry.st...@bblfish.net wrote:
>> 
>> As the WhatWG only recenly moved to Github members here may not have 
>> noticed that  has been deprecated.
>> 
>> I opened https://github.com/whatwg/html/issues/67 to give space for the 
>> discussion. It is a pitty that this was closed so quickly ( within an 
>> hour ) without giving members and the public ( the users of the web ) 
>> time to comment nor for their voice to be heard.
>> 
>> This is a complex issue that involves many different levels of 
>> expertise, and it should not be handled so lightly.
> 
> The spec just reflects implementations. The majority of implementations of 
>  (by usage) have said they want to drop it,

There was a lot of pushback on those lists against dropping it, and no
clear arguments have been made for dropping keygen there.

> and the other major  implementation has never supported it.

You mean IE? IE has always had something that did the same:
 
https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx

It is not idea, and it is easy to use both.

> The element was originally (and for 
> many years) purely a mostly-undocumented proprietary extension;

Adopted by most browsers. ( With IE having a similar feature just
done differently )

> at the 
> time it was invented, the HTML spec was edited by the W3C and the W3C did 
> not add it (they only ended up speccing it in their most recent HTML spec 
> because they forked the WHATWG's spec which did define it -- indeed, even 
> then, it was something that W3C HTML working group members argued should 
> not have been included). It was only added to the WHATWG spec because one 
> of the browser vendors said they could not remove support for it due to 
> usage by enterprise customers; that browser vendor is now amongst one of 
> the ones wanting to drop it.

To replace it with what? That is the problem that needs discussing and not 
partially
across twenty lists where the issues are only ever half addressed. 

> As far as I can tell, therefore, things here are working exactly as one 
> should expect.

Indeed: they seem to be working as one would expect where one thinking that 
forces
that don't like asymetric key cryptography to be widely deployed were trying to
remove that capability as far as possible. The manner of doing this - by secret 
evidence, and pointers to closed non deployed standards - seems to be very much
the way of doing of organisations that like to keep things secret and closed.

> 
> It's worth noting that  is a pretty terrible API. I recommend 
> approaching the groups writing new cryptography APIs, explaining your use 
> cases, and making sure they are supported in up-and-coming, more widely 
> supported, more secure, and more well-thought-out APIs.

The case has been made that things should go the other way around: the problems
should be brought up, and then improvements or replacements found. When those 
are
found and are satisfactory ( as evaluated against a wider set of values that 
take
the whole web security into account ) then one moves forward.



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

Social Web Architect
http://bblfish.net/

Re: [whatwg] deprecating

[Philip Jägenstedt]

On Wed, Sep 2, 2015 at 1:00 PM, henry.st...@bblfish.net
 wrote:
>
>> On 1 Sep 2015, at 19:56, Ian Hickson  wrote:
>>
>> As far as I can tell, therefore, things here are working exactly as one
>> should expect.
>
> Indeed: they seem to be working as one would expect where one thinking that 
> forces
> that don't like asymetric key cryptography to be widely deployed were trying 
> to
> remove that capability as far as possible. The manner of doing this - by 
> secret
> evidence, and pointers to closed non deployed standards - seems to be very 
> much
> the way of doing of organisations that like to keep things secret and closed.

This is borderline conspiratorial and is really not helpful. The first
message in the blink-dev thread [1] nicely summarizes the motivation.
If you distrust that and think that something more sinister is going
on, fine, but that's no way to have a fruitful discussion.

Lots of things have been removed from specs and implementations
following roughly the same "process", which is that some implementor
realizes that they'd like to remove something, check if other
implementors are on board, and then ask to have the spec changed.

[1] 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

Philip

Re: [whatwg] deprecating

[Ian Hickson]

On Tue, 1 Sep 2015, henry.st...@bblfish.net wrote:
>
> As the WhatWG only recenly moved to Github members here may not have 
> noticed that  has been deprecated.
> 
> I opened https://github.com/whatwg/html/issues/67 to give space for the 
> discussion. It is a pitty that this was closed so quickly ( within an 
> hour ) without giving members and the public ( the users of the web ) 
> time to comment nor for their voice to be heard.
> 
> This is a complex issue that involves many different levels of 
> expertise, and it should not be handled so lightly.

The spec just reflects implementations. The majority of implementations of 
 (by usage) have said they want to drop it, and the other major 
implementation has never supported it. The element was originally (and for 
many years) purely a mostly-undocumented proprietary extension; at the 
time it was invented, the HTML spec was edited by the W3C and the W3C did 
not add it (they only ended up speccing it in their most recent HTML spec 
because they forked the WHATWG's spec which did define it -- indeed, even 
then, it was something that W3C HTML working group members argued should 
not have been included). It was only added to the WHATWG spec because one 
of the browser vendors said they could not remove support for it due to 
usage by enterprise customers; that browser vendor is now amongst one of 
the ones wanting to drop it.

As far as I can tell, therefore, things here are working exactly as one 
should expect.

It's worth noting that  is a pretty terrible API. I recommend 
approaching the groups writing new cryptography APIs, explaining your use 
cases, and making sure they are supported in up-and-coming, more widely 
supported, more secure, and more well-thought-out APIs.

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

[whatwg] deprecating

[henry.st...@bblfish.net]

As the WhatWG only recenly moved to Github members here may not have noticed 
that  has been deprecated. 

I opened https://github.com/whatwg/html/issues/67 to give space for the 
discussion. It is a pitty that this was closed so quickly ( within an hour ) 
without giving members and the public ( the users of the web ) time to comment 
nor for their voice to be heard.

This is a complex issue that involves many different levels of expertise, and 
it should not be handled so lightly.

Henry


Social Web Architect
http://bblfish.net/

Re: [whatwg] Deprecating small , b ?

[Calogero Alex Baldacchino]

Tab Atkins Jr. ha scritto:

On Wed, Nov 26, 2008 at 4:48 PM, Calogero Alex Baldacchino
[EMAIL PROTECTED] wrote:
  


[cut]


We don't have to touch parsing at all to accomplish essentially this.The issue 
you're worried about is getting crazy semantics applied to
individual letters.  Semantic parsers (which honestly the average
browser is *not*) can easily just ignore the semantic value of b or
small or i when they don't wrap a full word, assuming that the use
is either stylistic or too complex/subtle to easily capture.

  


Well, such is a 'semantic' solution equivalent to leaving all to the 
implementation; a 'parsing' solution would solve the 'problem' at the 
bottom, but I acknowledge the question is too marginal to be seriously 
taken into account.


   


Agree to disagree, I guess.  I don't find We hope you'll find bProduct
A/b to be the best laundry detergent you've ever used! to be denoting
emphasis or importance, really.
  

I think 'Product A' is the core of the message, the thing some people are
trying to sell you, the name you *must* remember when you want to by a
laundry detergent, so those people become rich. The bold presentation aims
to capture your attention and keep your eyes on it a bit longer; on a
tv/radio spot the name of the product would be spoken out with some
isolation, with at least a bit of emphasis, for the same reasons. It denotes
importance meaning you need to pay a special attention to it in order to
understand *what the author wants you to understand*. I think that the same
semantics can be expressed by strong, since the importance of a piece of
text is not (only) in its meaning, or in the message overall meaning, or in
one's way to take it as important or not, but (also, or mainly) in the
author's intention to mark it as different from the rest of the content, as
a reading key, to drive your attention and as well your thoughts (ok, that's
like saying that truth is a chimera, but such can be a crude truth :-P ).



If I was contrasting Product A with another item, I could perhaps
agree.  But we're not, so I don't.  ^_^  However, we're obviously
splitting hairs here.
  


But you're implicitly contrasting 'Product A' with a bounce of generic 
items, all items of the same category your potential buyer might happen 
to know (I think this needs some clarification with one example, I guess 
you were referring to comparative advertising, which has not been legal 
in Italy for several years, so what you wrote - with some makup - has 
always been one of the most common advertisement here). Anyway, I agree 
we're splitting hairs, but there's some reason for me to push those 
concepts, and I hope I'll be able to make it clear.


  

Well, a foreign-language word, specially if correctly pronounced (by someone
else), can be more or less hard to 'catch', so a bit of emphasis in its
pronounce might help the listener to correctly distinguish sounds.



That's stretching quite a bit more than I think is appropriate.  Just
because I use a foreign phrase, does not mean that I'm emphasizing it.
 If I, in audible speech, would put a bit of inflection on the phrase,
that still doesn't mean I'm emphasizing it in anything like the way I
emphasize I'm emnot/em going to the dance with you!.
  


Isn't a bit of inflection also a bit of emphasis in pronounce? Perhaps 
I'm misusing the English term; that sounded correct at me in a wider 
sense, but I'll leave that concept, or modify it...



In other words, at most I might slightly stylistically offset the
phrase from my surrounding spoken words, but I wouldn't be
*emphasizing* them.  So the i semantics are correct here.  ^_^

  

After all, most of times bold and italicized texts (try and) reflect our way to
pronounce sentences, with more or less isolation, more or less emphasis,
quicker or slower, so changing their meaning, telling the listener that any
part requires a greater or a lesser attention, is somehow 'special', with
somehow different grades of 'speciality'. From this point of view, I think
either b/i can be semantically the very same thing as strong/em, or
their semantic should be redefined so to indicate a different (and lower)
grade of 'speciality' on the same speciality scale, but not as a different
kind of 'speciality' (i.e., b-text stands out for some - opaque - reason
which has nothing in common with strong-text).



You're overreaching your definition of importance and emphasis.  I
don't think it's valuable to denote *everything* that is in some way
special as important or emphatic - you lose a sense of scale.  If you
wish to define the words as such, then sure, b and i are lesser
grades of importance and emphasis by definition.  By more conventional
definitions, though, they're not, and their stated semantics are fine.

  


Ok, let's define 'special' in a more correct manner. What should be a 
slight offset? What does 'outstanding for some reason' mean, in a less 
ambigous definition? How should the offset 

Re: [whatwg] Deprecating small , b ?

[Calogero Alex Baldacchino]

Tab Atkins Jr. ha scritto:
On Tue, Nov 25, 2008 at 3:08 PM, Calogero Alex Baldacchino 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:


Tab Atkins Jr. ha scritto:



On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:








Do you mean that if you had markup like pbW/bhen I was 
young.../p, it would be read out as I was young...?  If so, that's 
clearly a bug in the reader, and has nothing to do with semantics or the 
lack of it.  There is *no* legitimate interpretation of that markup that 
would lead one to discard the first word.
 


I agree that a reading software unable to understand some text with 
unexpected typographic variants, should read it as normal text; however, 
 I guess how the above can result in an unexpected situation, when 
looking for non-typographic semantics.





Basically, there is a subset of authors who are morons, and they'll 
screw up anything we do.  Most of us aren't like that, but trying to 
design around that subset is a game you can't win.  Their pages will be 
FUBAR no matter what we do, until browsers' rendering engines are 
literally hooked up to a sentient semantic parser.


Arghh!! Such a software would be too smart and dominate the world... 
That could think, morons are bothering; human beings generate morons; 
no more human beings means no more bother for me


 


Ah, the default style could be slightly or very different from the
small one, i.e. the text could be surrounded by parenthesis or
hyphens, despite of the font size (and the new elements could be
designed such to accept just non-empty strings consisting of more
than one non-spacing character).


We could, but is there any reason to have it do that?  Making the text 
small is a good visual representation of the small print or aside 
semantics.




The concept was (or could be - let me modify it), the more we provide 
alternative visual representations of the aside semantic element, the 
more likely a moron designer will stay far from it, since he could be 
confused about the style he's creating. As well, the rule there is no 
default style for the element could prevent authoring tools from just 
changing the name of a button used to style some text. But I know, all 
would fail because most popular browser would choose very similar 
rendering (or would they just follow rendering small fonts).


Anyway, I wouldn't underestimate the latter characteristic (ok, that 
wasn't clear), that is establishing the use of the element is legal if 
it sorrunds a piece of text made up of one or more whole words (or at 
least one readable character) and if it's bounded by spacing or 
punctuation characters (that is, the 'semantic element' cannot be a part 
of a word). Of course, the misuse concern would just move from the 
messed-up word to a messed-up sentence, but at least, in this case, an 
assistive reader would be less likely fouled up and, without any need 
for luck, it could speak out something funny, yet understandable. Of 
course the same could be done redefining b and small parsing rules, 
but such would result in a break with a bounch of (possible) legacy 
uses, and if we had to break somehow with the past, why don't have a 
look for some more significant names? - Just to say, not hoping to 
persuade you :-P




Here it is me not understanding. I think that any reason to offset
some text from the surrounding one can be reduced to the different
grade of 'importance' the author gives it, in the same meaning as
Smylers used in his mails (that is, not the importance of the
content, but the relevance it gets as attention focus - he made the
example of the English small print idiom, and in another mail
clarified that It's less important in the sense that it isn't the
point of what the author wants users to have conveyed to them; it's
less important to the message. (Of course, to users any caveats in
the small print may be very important indeed!)). From this point of
view, unless we aimed to avail of b as an intermediate grade of
relevance between 'normal text' and 'em/strong' (but, aren't these
enough to attract a reader's attention?), redefining its semantic
might be redundant with lesser utility. (In my crazy mind, this
applies to the headings too, since a 'good' heading focuses
attention on the core subject of its following section, so have to
be evidenced as an important slice of text). Furthermore, I meant
that strong and em would have been a better choice than b in
Smylers' examples because their *original semantics* is very close
together with that of a more relevant text/a text needing greater
attention, while b *original semantics* is very different and
needs to be redefined for this purpose (but we have still got
possible alternatives to this).

Re: [whatwg] Deprecating small , b

[Smylers]

Pentasis writes:

 [Asbjørn Ulsberg writes:]
 
  However, as you write and as HTML5 defines it, there is nothing
  wrong with small per se, and I agree that as an element indicating
  smallprint, it works just fine.
 
  Since my initial reply might have been a bit too colored by the HTML4  
  definition of the element and its current usage on the web, I hereby  
  withdraw my comment and conclude that I mostly agree with you. :-)

Yay, consensus!  Thanks, Asbjørn.

 But isn't this just the reason why it should be dis-used?  The HTML4
 spec defined it as a styling tag, and that is how it is *mostly* used
 and understood by the majority of the users/authors.

That may be true (though authors who want smaller text just because they
think the default looks too large could also use font size=2 or CSS),
but authors who wanted to diminished the emphasis of certain content to
users are likely to pick small because there isn't much else
available.

Just because an element is currently widely used for a purpose we deem
inappropriate doesn't mean that its appropriate uses aren't important.
Tables are widely used for layout; br-s are widely misused.  Both of
those clearly have other valid uses, so are still in HTML.

 Just because HTML5 redefines the element does not mean that the
 element will suddenly be semantic. Even if people start using it
 purely semantically from now on (and what is the chance of that?), the
 existing websites still carry small-tags that are not compliant with
 the new definition.

Yes.  But the suggested alternative was to deprecate small entirely
and invent a new element to convey the semantic of 'small print'.  That
would of course make _all_ current uses of small non-conforming.
Presentational small-s are going to be non-conforming either way;
allowing semantic small-s to conform doesn't change that.

 By redefining it the (existing) web breaks; allbeit purely in the
 semantic area. 

That's intentional.  If anybody checks legacy content against the new
standard they will discover that what they did is no longer recommended.
However, browsers will 100% support it and continue to render it as it
always has been, so the 'breakage' is no way visible; if the author
chooses not to care about it then no harm is done.

Smylers

PS: Pentasis, please could you send mails that do at least one of
attributing who you're quoting or include In-Reply-To: headers so that
they continue the existing thread rather than starting a new one.
Without either it's rather tedious to have to look up who said the text
you quote.  Thanks.

Re: [whatwg] Deprecating small , b ?

[Calogero Alex Baldacchino]

Smylers wrote:

Asbjørn Ulsberg writes:

  

On Mon, 17 Nov 2008 15:26:22 +0100, Smylers [EMAIL PROTECTED]
wrote:



In printed material users are typically given no out-of-band
information about the semantics of the typesetting.  However,
smaller things are less noticeable, and it's generally accepted that
the author of the document wishes the reader to pay less attention
to them than more prominent things.

That works fine with small .
  

No, it doesn't, and you explain why yourself here:



User-agents which can't literally render smaller fonts can choose
alternative mechanisms for denoting lower importance to users.
  


I don't see how that explains why small is an inappropriate tag to use
for things which an author wishes to be less noticeable.
[...]
  


Of course that's possible, but, as you noticed too, only by redefining 
the small semantics, and is not a best choice per se. That's both 
because the original semantics for the small tag was targeted to 
styling and nothing else (the html 4 document type definitions declared 
it as a member of the fontstyle entity, while, for instance, strong 
and em were parts of the phrase entity), and because the term 'small', 
at first glance, suggests the idea of a typographical function, 
regardless any other related concept which might be specific for the 
English (or whatever else) culture, but might not be as well immediate 
for non-English developers all around the world. As a consequence, since 
any average developer could just rely on the old semantics, being he 
intuitively confident with it, the semantics redefinition could find a 
first counter-indication: let's think on a word written with alternate 
b and small letters, or just to a paragraph first letter evidenced 
by a b, obviously the application of the new semantics here would be 
untrivial (i.e. an assistive software for blind users would be fouled by 
this and give unpredictable results). Despite the previous use case 
would be a misuse of the b and small markup, yet it would be 
possible, meaning not prohibited, and so creating a new element with a 
proper semantic could be a better choice.


But, you're right, we have to deal with backward compatibility, and 
redefining the small and b semantics can be a good compromise, since 
a new element would face some heavy concerns, mainly related to 
rendering and to the state of the art implementations in non-visual user 
agents (and the alike).


However, I think that a solution, at least partial, can be found for the 
rendering concern (and I'd push for this being done anyway, since there 
are several new elements defined for HTML 5). Most user agents are 
capable to interpret a dtd to some extent, so it could be worth the 
effort to define an html 5 specific dtd in addition to the parsing 
roules - which aim to overcome all problems arising by previous dtd-only 
html specifications - so that a non html5-fully-compliant browser can 
somehow interpret any new elements. HTML 5 Doctype declaration could 
accept a dtd just for backward compatibility purpose, and any fully 
compliant user agent would just ignore such dtd. More specifically, such 
a dtd could define default values for some attributes, such as the style 
attribute (to have any new element properly rendered - some assistive 
technologies are capable to interpret style sheets too), and, anyway, 
there should be a way, in SMGL, to create an alias for an element (i.e., 
a new element - let's call it incidental - could be aliased to small 
for better compatibility).


Let's come to the non-typographical interpretation a today u.a. may be 
capable of, as in your example about lynx. This can be a very good 
reason to deem small a very good choice. But, are we sure that *every* 
existing user agent can do that? If the answer is yes, we can stop here: 
small is a perfect choise. Better: small is all we need, so let's 
stop bothering each other about this matter. But if the answer is no, we 
have to face a number of user agents needing an update to understand the 
new semantics for the small tag, and so, if the new semantics can be 
assumed as *surely* reliable only with new/updated u.a.'s (that is, with 
those ones fully compatible with html 5 specifications), that's somehow 
like to be starting from scratch, and consequently there is space for a 
new, more appropriate element.



However, you would appreciate that the author had wished for some
particular words to stand out from the surrounding text.
  

That's a job for the style sheet, whether it's provided by the author
or by the user agent.



The style-sheet can only pick out particular words if those words have
been marked-up as special in the document, so it doesn't solve the
problem of how to mark them up.

Further, this isn't using b because the house style is to have all
text in a bold weight (that can be done by style-sheets, and if the
style-sheet is missing all the content is still there); it's using b
to 

Re: [whatwg] Deprecating small , b ?

[Tab Atkins Jr.]

On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino 
[EMAIL PROTECTED] wrote:

 Smylers wrote:

 Asbjørn Ulsberg writes:



 On Mon, 17 Nov 2008 15:26:22 +0100, Smylers [EMAIL PROTECTED]
 wrote:



 In printed material users are typically given no out-of-band
 information about the semantics of the typesetting.  However,
 smaller things are less noticeable, and it's generally accepted that
 the author of the document wishes the reader to pay less attention
 to them than more prominent things.

 That works fine with small .


 No, it doesn't, and you explain why yourself here:



 User-agents which can't literally render smaller fonts can choose
 alternative mechanisms for denoting lower importance to users.



 I don't see how that explains why small is an inappropriate tag to use
 for things which an author wishes to be less noticeable.
 [...]



 Of course that's possible, but, as you noticed too, only by redefining the
 small semantics, and is not a best choice per se. That's both because the
 original semantics for the small tag was targeted to styling and nothing
 else (the html 4 document type definitions declared it as a member of the
 fontstyle entity, while, for instance, strong and em were parts of the
 phrase entity), and because the term 'small', at first glance, suggests the
 idea of a typographical function, regardless any other related concept which
 might be specific for the English (or whatever else) culture, but might not
 be as well immediate for non-English developers all around the world. As a
 consequence, since any average developer could just rely on the old
 semantics, being he intuitively confident with it, the semantics
 redefinition could find a first counter-indication: let's think on a word
 written with alternate b and small letters, or just to a paragraph first
 letter evidenced by a b, obviously the application of the new semantics
 here would be untrivial (i.e. an assistive software for blind users would be
 fouled by this and give unpredictable results). Despite the previous use
 case would be a misuse of the b and small markup, yet it would be
 possible, meaning not prohibited, and so creating a new element with a
 proper semantic could be a better choice.


No matter *what* we do, if there *is* a default style for an element, it
will be misused by people.  This is a fact of life.  Defining a new element
which is identical to small in every way except that it hasn't been
misused *yet* is thus a mug's game, because it *will* be misused in the same
way as small, and then we just have two identical elements for no reason.

Yes, bad markup will foul up semantic agents.  But people will *always*
write bad markup.  At least with the semantic redefinition we get to declare
lots of usages that *are* appropriate to be conforming without any effort on
the author's part.

And really, the type of people who would write a word with alternating
letters wrapped in b and small tags are hardly the kind to even *care*
about semantics.

But, you're right, we have to deal with backward compatibility, and
 redefining the small and b semantics can be a good compromise, since a
 new element would face some heavy concerns, mainly related to rendering and
 to the state of the art implementations in non-visual user agents (and the
 alike).

 However, I think that a solution, at least partial, can be found for the
 rendering concern (and I'd push for this being done anyway, since there are
 several new elements defined for HTML 5). Most user agents are capable to
 interpret a dtd to some extent, so it could be worth the effort to define an
 html 5 specific dtd in addition to the parsing roules - which aim to
 overcome all problems arising by previous dtd-only html specifications - so
 that a non html5-fully-compliant browser can somehow interpret any new
 elements. HTML 5 Doctype declaration could accept a dtd just for backward
 compatibility purpose, and any fully compliant user agent would just ignore
 such dtd. More specifically, such a dtd could define default values for some
 attributes, such as the style attribute (to have any new element properly
 rendered - some assistive technologies are capable to interpret style sheets
 too), and, anyway, there should be a way, in SMGL, to create an alias for an
 element (i.e., a new element - let's call it incidental - could be aliased
 to small for better compatibility).


Html5 is no longer an SGML language.


 Let's come to the non-typographical interpretation a today u.a. may be
 capable of, as in your example about lynx. This can be a very good reason to
 deem small a very good choice. But, are we sure that *every* existing user
 agent can do that? If the answer is yes, we can stop here: small is a
 perfect choise. Better: small is all we need, so let's stop bothering each
 other about this matter. But if the answer is no, we have to face a number
 of user agents needing an update to understand the new semantics for the
 small tag, and 

Re: [whatwg] Deprecating small , b ?

[Calogero Alex Baldacchino]

Tab Atkins Jr. ha scritto:



On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:



Of course that's possible, but, as you noticed too, only by
redefining the small semantics, and is not a best choice per se.
That's both because the original semantics for the small tag was
targeted to styling and nothing else (the html 4 document type
definitions declared it as a member of the fontstyle entity,
while, for instance, strong and em were parts of the phrase
entity), and because the term 'small', at first glance, suggests
the idea of a typographical function, regardless any other related
concept which might be specific for the English (or whatever else)
culture, but might not be as well immediate for non-English
developers all around the world. As a consequence, since any
average developer could just rely on the old semantics, being he
intuitively confident with it, the semantics redefinition could
find a first counter-indication: let's think on a word written
with alternate b and small letters, or just to a paragraph
first letter evidenced by a b, obviously the application of the
new semantics here would be untrivial (i.e. an assistive software
for blind users would be fouled by this and give unpredictable
results). Despite the previous use case would be a misuse of the
b and small markup, yet it would be possible, meaning not
prohibited, and so creating a new element with a proper semantic
could be a better choice. 



No matter *what* we do, if there *is* a default style for an element, 
it will be misused by people.  This is a fact of life.  Defining a new 
element which is identical to small in every way except that it 
hasn't been misused *yet* is thus a mug's game, because it *will* be 
misused in the same way as small, and then we just have two 
identical elements for no reason.


I'll start with an example. A few time ago I played around with Opera 
Voice. It seemed to be capable to interpret visual style sheets and 
specifically font styles, so that bold or italics text (so constraint in 
the style sheet, not the markup) were spoken differently from 'normal' 
text, but a paragraph first letter differing from the rest of the word 
(which is a non-rare typographical choice), as far as I remember, caused 
the whole word to be skipped. This suggests me that if we really want a 
'cross-presentation' semantics, we have to keep as far as we can from 
anything having a *main* typographical semantics (as small and b 
have from their birth). Every language is somehow prone to side-effects 
caused by misuse (i.e. it is possible to cause a big mess in a software 
written in a language allowing to pass a pointer to a function - there 
are tons of examples for language design issues - yet such could be a 
desireable capability), but appropriate choices for both semantics and 
syntax may help to reduce the likelyhood of a misuse.


I think that very likely both b and small will carry on their old 
semantics, so being more prone to misuse with respect to their new one, 
since very likely a lot of developers are, and will rest, more confident 
with their original semantics, which is also suggested by their names 
('b' standing for 'bold' and 'small'... for something small on the 
screen or on paper). Instead, a new element would require the developer 
to take some effort at least to learn about its existence, so he would 
read that such element primary use is to indicate a different importance 
of a piece of text, so that a non visual user agent can present it in an 
appropriate manner, and a visual or print user agent can render it in 
different ways. Ah, the default style could be slightly or very 
different from the small one, i.e. the text could be surrounded by 
parenthesis or hyphens, despite of the font size (and the new elements 
could be designed such to accept just non-empty strings consisting of 
more than one non-spacing character).




Yes, bad markup will foul up semantic agents.  But people will 
*always* write bad markup.  At least with the semantic redefinition we 
get to declare lots of usages that *are* appropriate to be conforming 
without any effort on the author's part.


And really, the type of people who would write a word with alternating 
letters wrapped in b and small tags are hardly the kind to even 
*care* about semantics.


Let me reverse this approach: what should an assistive user agent do 
with such a bM/bsmallE/smallbS/bsmallS/small? I think 
that dealing with that word as normal text would be a more gracefull 
degradation than discarding it, and if we clearly state that b and 
small have only typographical semantics, while different elements are 
provided to differentiate the grade of emphasys of a phrase, an 
assistive user agent could support a better behaviour, while any author 
disregarding semantics would not cause any trouble (the 

Re: [whatwg] Deprecating small , b ?

[Tab Atkins Jr.]

On Tue, Nov 25, 2008 at 3:08 PM, Calogero Alex Baldacchino 
[EMAIL PROTECTED] wrote:

 Tab Atkins Jr. ha scritto:



 On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino 
 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:


Of course that's possible, but, as you noticed too, only by
redefining the small semantics, and is not a best choice per se.
That's both because the original semantics for the small tag was
targeted to styling and nothing else (the html 4 document type
definitions declared it as a member of the fontstyle entity,
while, for instance, strong and em were parts of the phrase
entity), and because the term 'small', at first glance, suggests
the idea of a typographical function, regardless any other related
concept which might be specific for the English (or whatever else)
culture, but might not be as well immediate for non-English
developers all around the world. As a consequence, since any
average developer could just rely on the old semantics, being he
intuitively confident with it, the semantics redefinition could
find a first counter-indication: let's think on a word written
with alternate b and small letters, or just to a paragraph
first letter evidenced by a b, obviously the application of the
new semantics here would be untrivial (i.e. an assistive software
for blind users would be fouled by this and give unpredictable
results). Despite the previous use case would be a misuse of the
b and small markup, yet it would be possible, meaning not
prohibited, and so creating a new element with a proper semantic
could be a better choice.

 No matter *what* we do, if there *is* a default style for an element, it
 will be misused by people.  This is a fact of life.  Defining a new element
 which is identical to small in every way except that it hasn't been
 misused *yet* is thus a mug's game, because it *will* be misused in the same
 way as small, and then we just have two identical elements for no reason.


 I'll start with an example. A few time ago I played around with Opera
 Voice. It seemed to be capable to interpret visual style sheets and
 specifically font styles, so that bold or italics text (so constraint in the
 style sheet, not the markup) were spoken differently from 'normal' text, but
 a paragraph first letter differing from the rest of the word (which is a
 non-rare typographical choice), as far as I remember, caused the whole word
 to be skipped.


Do you mean that if you had markup like pbW/bhen I was young.../p,
it would be read out as I was young...?  If so, that's clearly a bug in
the reader, and has nothing to do with semantics or the lack of it.  There
is *no* legitimate interpretation of that markup that would lead one to
discard the first word.


 This suggests me that if we really want a 'cross-presentation' semantics,
 we have to keep as far as we can from anything having a *main* typographical
 semantics (as small and b have from their birth). Every language is
 somehow prone to side-effects caused by misuse (i.e. it is possible to cause
 a big mess in a software written in a language allowing to pass a pointer to
 a function - there are tons of examples for language design issues - yet
 such could be a desireable capability), but appropriate choices for both
 semantics and syntax may help to reduce the likelyhood of a misuse.

 I think that very likely both b and small will carry on their old
 semantics, so being more prone to misuse with respect to their new one,
 since very likely a lot of developers are, and will rest, more confident
 with their original semantics, which is also suggested by their names ('b'
 standing for 'bold' and 'small'... for something small on the screen or on
 paper). Instead, a new element would require the developer to take some
 effort at least to learn about its existence, so he would read that such
 element primary use is to indicate a different importance of a piece of
 text, so that a non visual user agent can present it in an appropriate
 manner, and a visual or print user agent can render it in different ways.


Well, the new semantics are purposely very close to the old 'semantics'.
Bold text *is* text purposely offset from the surrounding prose.  Some
legacy uses of b are more correctly done with other existing elements,
like strong or h1, but at least it's *close*.

And again, the type of author who *is* marking up random things with b for
purely stylistic reasons isn't the sort who is going around reading
standards documents, or likely even caring in the slightest.  If they *did*
discover a new element that has the correct semantics (like standout or
something), they'll either ignore it (if it's basically identical to b) or
use it nonsemantically as well (if it offers some exciting new default
styling).

Basically, there is a subset of authors who are morons, and they'll screw up
anything we do.  Most of us aren't like that, but 

Re: [whatwg] Deprecating small , b ?

[Asbjørn Ulsberg]

On Mon, 17 Nov 2008 15:26:22 +0100, Smylers [EMAIL PROTECTED] wrote:


In printed material users are typically given no out-of-band information
about the semantics of the typesetting.  However, smaller things are
less noticeable, and it's generally accepted that the author of the
document wishes the reader to pay less attention to them than more
prominent things.

That works fine with small.


No, it doesn't, and you explain why yourself here:


User-agents which can't literally render smaller fonts can choose
alternative mechanisms for denoting lower importance to users.


If the point isn't to literally render smaller fonts, you shouldn't
indicate that you want the fonts rendered smaller either. What you want is
to semantically indicate that the text wrapped inside the element is of
less significance than the surrounding text, e.g. a negative 'strong' or
'em'. Just as 'b' isn't equal to 'strong', 'small' isn't equal to what
we're trying to express here.

What we need is a new element that can capture this semantic.


Denoting particular text as being of lessor importance is quite
different from choosing the overall base font size (or indeed typeface)
for the page, or the colour of links or headings -- that's merely
expressing a preference for how graphical user-agents should render
particular semantics, but the semantics themselves are conveyed to _all_
user-agents (a, h3, etc).


Which is why we need to capture this as semantic and not as presentational
sugar.


Indeed you can't.  And nor can you if you were reading printed text with
some words in bold.


Why does printed text set the standard for what we are able to express
with a markup language? Does e.g. PDF in any way direct what should be
possible with HTML?


However, you would appreciate that the author had wished for some
particular words to stand out from the surrounding text.


That's a job for the style sheet, whether it's provided by the author or
by the user agent. Using the same element would in most circumstances
yield the same presentation. Isn't that what you want?


However, you can only notice this if the words have been distinguished
in some way.  With b, all user-agents can choose to convey to users
that those words are special.


They are only special for sighted users, browsing the page with a rather
advanced user agent. They are not special to blind users or to users of
text-based user agents like Lynx. If you want to express semantics, then
use a semantic element.

Expressing semantics through presentation only is done in print because of
the limitations in the printing system. If the print was for a blind
person, printed with braille, one could imagine (had it been supported)
that letters with a higher weight could be physically warmer than others,
or with a more jagged edge so they could stand out.

Such effects would have been impossible if the document was only tagged
with presentational markup. The same applies to other mediums than print
-- you need to know the underlying reason of why something is presented
the way it is to transfer that presentation to another environment. And
for that you need the semantics.

--
Asbjørn Ulsberg   -=|=-[EMAIL PROTECTED]
«He's a loathsome offensive brute, yet I can't look away»

Re: [whatwg] Deprecating small , b ?

[Smylers]

Asbjørn Ulsberg writes:

 On Mon, 17 Nov 2008 15:26:22 +0100, Smylers [EMAIL PROTECTED]
 wrote:
 
  In printed material users are typically given no out-of-band
  information about the semantics of the typesetting.  However,
  smaller things are less noticeable, and it's generally accepted that
  the author of the document wishes the reader to pay less attention
  to them than more prominent things.
 
  That works fine with small .
 
 No, it doesn't, and you explain why yourself here:
 
  User-agents which can't literally render smaller fonts can choose
  alternative mechanisms for denoting lower importance to users.

I don't see how that explains why small is an inappropriate tag to use
for things which an author wishes to be less noticeable.

 If the point isn't to literally render smaller fonts, you shouldn't
 indicate that you want the fonts rendered smaller either.

Indeed.  font size=-1 would be bad to use for this.

 What you want is to semantically indicate that the text wrapped inside
 the element is of less significance than the surrounding text, e.g. a
 negative 'strong' or 'em'.

Yes.  And I reckon than small works for that.  English has the idiom
of 'small print', roughly meaning text written by the legal department
rather than the marketing department.  But 'small print' doesn't
literally have to be typeset with a smaller font; it's a figure of
speech.

 'small' isn't equal to what we're trying to express here.  What we
 need is a new element that can capture this semantic.

If we were starting from scratch then indeed small may not be the best
name to choose for this element.  But, unfortunately, we aren't.

small has existed for some time, and people are already using it.  If
one currently wants to denote lessor importance small is the best
element to pick.  Further, existing browsers know what to do with
small; if we introduce a new element then content that uses it will
have a sub-optimal rendering in current browsers, whereas small
already does something appropriate.

So I still think small works for denoting that something is of smaller
importance.

  Indeed you can't.  And nor can you if you were reading printed text
  with some words in bold.
 
 Why does printed text set the standard for what we are able to express
 with a markup language?

It doesn't set the standard.  But it's useful in some comparisons.  And
most of the time humans cope perfectly well with inferring typographic
conventions without having them spelt out.

  However, you would appreciate that the author had wished for some
  particular words to stand out from the surrounding text.
 
 That's a job for the style sheet, whether it's provided by the author
 or by the user agent.

The style-sheet can only pick out particular words if those words have
been marked-up as special in the document, so it doesn't solve the
problem of how to mark them up.

Further, this isn't using b because the house style is to have all
text in a bold weight (that can be done by style-sheets, and if the
style-sheet is missing all the content is still there); it's using b
to convey _some_ semantics: namely that those particular words are in
some way special.

So if the mark-up is span class=brand_name or similar and the
distinguishing presentation added with CSS then users without
style-sheets are completely unaware that the author identified those
words as being special.  Whereas with b, everybody gets to know.

  However, you can only notice this if the words have been
  distinguished in some way.  With b , all user-agents can choose to
  convey to users that those words are special.
 
 They are only special for sighted users, browsing the page with a
 rather advanced user agent. They are not special to blind users or to
 users of text-based user agents like Lynx.

Not true.  Any user-agent can choose to convey that words marked in b
are somehow different from the surrounding words.  Lynx does this.

 If you want to express semantics, then use a semantic element.

That's begging the question.  If we define b to be semantic, then it
is!

 Expressing semantics through presentation only is done in print
 because of the limitations in the printing system.

Well, yes.

 If the print was for a blind person, printed with braille, one could
 imagine (had it been supported) that letters with a higher weight
 could be physically warmer than others, or with a more jagged edge so
 they could stand out.

Yup -- and an HTML-to-braille converter could choose to do that with
words marked in b, whereas it couldn't with span class=BrandName.

 Such effects would have been impossible if the document was only
 tagged with presentational markup.

To some extent, yes: not knowing whether a letter is where it is on the
page because it's a start of a paragraph or a heading, or just because
the previous line is full, hampers doing that.  And similarly for
typefaces.

 The same applies to other mediums than print -- you need to know the
 underlying reason of why 

Re: [whatwg] Deprecating small, b ?

[Lachlan Hunt]

Nils Dagsson Moskopp wrote:

The small element represents small print [...]



The b element represents a span of text to be stylistically offset from

the normal prose without conveying any extra importance [...]

Both definitions seems rather presentational (contrasting, for example,
the new semantic definition for the i element) and could also be
realized by use of span elements.

To me these look like the last remnants of the font element. So why
are these elements retained ?


This issue has been discussed in depth in the past; most significantly 
on public-html around May 2007.


http://lists.w3.org/Archives/Public/www-html/2007May/thread.html#msg3
(I think most of the releant discussion is in the Cleaning House thread)

I have added an entry to the FAQ detailing the rationale for including 
these elements, and have previously written an article about the issue too.


http://wiki.whatwg.org/wiki/FAQ#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F
http://lachy.id.au/log/2007/05/b-and-i
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] Deprecating small , b ?

[Felix Miata]

On 2008/11/24 16:19 (GMT) Smylers composed:

 So I still think small works for denoting that something is of smaller
 importance.

I do too, but I don't believe less importance can be the only inference. One
could simply want smaller text, without expecting that inference. e.g., just
because fine print legalese is called what it is doesn't doesn't
necessarily make it unimportant or less important. I'm for keeping small in
the spec.
-- 
Love is not easily angered. Love does not demand
its own way.   1 Corinthians 13:5 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

Re: [whatwg] Deprecating small , b ?

[Smylers]

Felix Miata writes:

 On 2008/11/24 16:19 (GMT) Smylers composed:
 
  So I still think small works for denoting that something is of
  smaller importance.
 
 I do too, but I don't believe less importance can be the only
 inference. One could simply want smaller text, without expecting that
 inference.

If you just want something to be smaller stylistically and there's
nothing special about that portion of the text then I think using
small for it would be as bad as using h1 just to make text bigger;
CSS is a better choice.

 e.g., just because fine print legalese is called what it is doesn't
 doesn't necessarily make it unimportant or less important.

It's less important in the sense that it isn't the point of what the
author wants users to have conveyed to them; it's less important to the
message.  (Of course, to users any caveats in the small print may be
very important indeed!)

Smylers

Re: [whatwg] Deprecating small , b ?

[Asbjørn Ulsberg]

On Mon, 24 Nov 2008 17:19:44 +0100, Smylers [EMAIL PROTECTED] wrote:


I don't see how that explains why small is an inappropriate tag to use
for things which an author wishes to be less noticeable.


I was thinking mostly about the tag's current usage on the web, which is a crazy mix 
between the HTML4 and HTML5 definition of the element. HTML4 defines it purely 
presentational, HTML5 mostly semantical. In that context, I believe small is 
inappropriate.

However, as you write and as HTML5 defines it, there is nothing wrong with small per 
se, and I agree that as an element indicating smallprint, it works just fine.

Since my initial reply might have been a bit too colored by the HTML4 
definition of the element and its current usage on the web, I hereby withdraw 
my comment and conclude that I mostly agree with you. :-)

--
Asbjørn Ulsberg -=|=-  [EMAIL PROTECTED]
«He's a loathsome offensive brute, yet I can't look away»

Re: [whatwg] Deprecating small , b

[Pentasis]

I was thinking mostly about the tag's current usage on the web, which is a 
crazy mix between the HTML4 and HTML5 definition of the element. HTML4 
defines it purely presentational, HTML5 mostly semantical. In that 
context, I believe small is inappropriate.


However, as you write and as HTML5 defines it, there is nothing wrong with 
small per se, and I agree that as an element indicating smallprint, it 
works just fine.


Since my initial reply might have been a bit too colored by the HTML4 
definition of the element and its current usage on the web, I hereby 
withdraw my comment and conclude that I mostly agree with you. :-)




But isn't this just the reason why it should be dis-used?
The HTML4 spec defined it as a styling tag, and that is how it is *mostly* 
used and understood by the majority of the users/authors.
Just because HTML5 redefines the element does not mean that the element will 
suddenly be semantic. Even if people start using it purely semantically from 
now on (and what is the chance of that?), the existing websites still carry 
small-tags that are not compliant with the new definition. By redefining it 
the (existing) web breaks; allbeit purely in the semantic area. 

Re: [whatwg] Deprecating small , b

[Jonas Sicking]

Pentasis wrote:


I was thinking mostly about the tag's current usage on the web, which 
is a crazy mix between the HTML4 and HTML5 definition of the element. 
HTML4 defines it purely presentational, HTML5 mostly semantical. In 
that context, I believe small is inappropriate.


However, as you write and as HTML5 defines it, there is nothing wrong 
with small per se, and I agree that as an element indicating 
smallprint, it works just fine.


Since my initial reply might have been a bit too colored by the HTML4 
definition of the element and its current usage on the web, I hereby 
withdraw my comment and conclude that I mostly agree with you. :-)




But isn't this just the reason why it should be dis-used?
The HTML4 spec defined it as a styling tag, and that is how it is 
*mostly* used and understood by the majority of the users/authors.
Just because HTML5 redefines the element does not mean that the element 
will suddenly be semantic. Even if people start using it purely 
semantically from now on (and what is the chance of that?), the existing 
websites still carry small-tags that are not compliant with the new 
definition. By redefining it the (existing) web breaks; allbeit purely 
in the semantic area.


Note that the semantic meaning that HTML5 gives it is very weak. All it 
says is that the text inside the b is different from the text outside 
it. All the existing uses on the web that I've seen are correct 
according to this semantic definition.


Do you have any counter examples of this, where the b was containing 
something that was exactly semantically the same as the surrounding content?


/ Jonas

Re: [whatwg] Deprecating small , b

[Nils Dagsson Moskopp]

Am Montag, den 24.11.2008, 15:10 -0800 schrieb Jonas Sicking:
 Note that the semantic meaning that HTML5 gives it is very weak. All it 
 says is that the text inside the b is different from the text outside 
 it. All the existing uses on the web that I've seen are correct 
 according to this semantic definition.
Weak in this case means: Not of much semantic, probably only of presentational 
use.

So can't we just mark all presentational elements as obsolete in a
clear, consistenst way, instead of trying to redefine them ? Maybe put
them into a presentational annex of the spec, that defines rendering
of obsolete elements ?

The thing I am concerned with is that if they are included like
normal (read: semantic) elements, authors will probably use them for
new pages.


Cheers,

Nils

Re: [whatwg] Deprecating small , b ?

[Smylers]

Pentasis writes:

 2) When using small on different text-nodes throughout the document,
 one would expect all these text-nodes to be semantically the same. But
 they are not (unless all of them are copyright notices).

In printed material users are typically given no out-of-band information
about the semantics of the typesetting.  However, smaller things are
less noticeable, and it's generally accepted that the author of the
document wishes the reader to pay less attention to them than more
prominent things.

That works fine with small.  User-agents which can't literally render
smaller fonts can choose alternative mechanisms for denoting lower
importance to users.

There's no chance of doing this with span class=legalese or similar,
since user-agents are unaware of the semantic they should be conveying.

 3) small is a styling element, it has zero semantic meaning, so it does 
 not belong inside HTML.

Denoting particular text as being of lessor importance is quite
different from choosing the overall base font size (or indeed typeface)
for the page, or the colour of links or headings -- that's merely
expressing a preference for how graphical user-agents should render
particular semantics, but the semantics themselves are conveyed to _all_
user-agents (a, h3, etc).

 4) b Siemens/b also does not tell me anything about the semantics.
 Is it used as a name, a brand a foreign word ? etc. I cannot get that
 information from looking at the b element.

Indeed you can't.  And nor can you if you were reading printed text with
some words in bold.  However, you would appreciate that the author had
wished for some particular words to stand out from the surrounding text.
Perhaps you then notice it's being done for all brand names?  Or that
the emboldened words spell out a secret message?

However, you can only notice this if the words have been distinguished
in some way.  With b, all user-agents can choose to convey to users
that those words are special.

Smylers

Re: [whatwg] Deprecating small , b ?

[Pentasis]

2) When using small on different text-nodes throughout the document,
one would expect all these text-nodes to be semantically the same. But
they are not (unless all of them are copyright notices).


In printed material users are typically given no out-of-band information
about the semantics of the typesetting.  However, smaller things are
less noticeable, and it's generally accepted that the author of the
document wishes the reader to pay less attention to them than more
prominent things.

That works fine with small.  User-agents which can't literally render
smaller fonts can choose alternative mechanisms for denoting lower
importance to users.

There's no chance of doing this with span class=legalese or similar,
since user-agents are unaware of the semantic they should be conveying.


3) small is a styling element, it has zero semantic meaning, so it does
not belong inside HTML.


Denoting particular text as being of lessor importance is quite
different from choosing the overall base font size (or indeed typeface)
for the page, or the colour of links or headings -- that's merely
expressing a preference for how graphical user-agents should render
particular semantics, but the semantics themselves are conveyed to _all_
user-agents (a, h3, etc).


4) b Siemens/b also does not tell me anything about the semantics.
Is it used as a name, a brand a foreign word ? etc. I cannot get that
information from looking at the b element.


Indeed you can't.  And nor can you if you were reading printed text with
some words in bold.  However, you would appreciate that the author had
wished for some particular words to stand out from the surrounding text.
Perhaps you then notice it's being done for all brand names?  Or that
the emboldened words spell out a secret message?

However, you can only notice this if the words have been distinguished
in some way.  With b, all user-agents can choose to convey to users
that those words are special.

Smylers



You cannot make a 100% comparison between printed and web-published styling 
and semantics. Apart from the obvious visual difference, we are talking 
about the ability here to convey semantics other than just visual. For 
example to aid machine-readability but far more importantly, Assistive 
Technologies.
If markup in web-publishing was meant to be just for visual feedback, we 
would only need 1 block and one inline element as we can do anything with 
just classes and CSS in that respect. In that case you would be right, as 
indeed a book, newspaper or magazine can be read just fine without using 
markup-elements. And so can webpages. But this is not the main reason behind 
the semantic web.


Bert 

Re: [whatwg] Deprecating small , b ?

[Smylers]

Pentasis writes:

  In printed material users are typically given no out-of-band
  information about the semantics of the typesetting.  However,
  smaller things are less noticeable, and it's generally accepted that
  the author of the document wishes the reader to pay less attention
  to them than more prominent things.
  
  That works fine with small.  User-agents which can't literally
  render smaller fonts can choose alternative mechanisms for denoting
  lower importance to users.
  
  There's no chance of doing this with span class=legalese or
  similar, since user-agents are unaware of the semantic they should
  be conveying.
  
   3) small is a styling element, it has zero semantic meaning, so
   it does not belong inside HTML.
  
  Denoting particular text as being of lessor importance is quite
  different from choosing the overall base font size (or indeed
  typeface) for the page, or the colour of links or headings -- that's
  merely expressing a preference for how graphical user-agents should
  render particular semantics, but the semantics themselves are
  conveyed to _all_ user-agents (a , h3 , etc).
  
   4) b Siemens/b also does not tell me anything about the
   semantics.  Is it used as a name, a brand a foreign word ? etc. I
   cannot get that information from looking at the b element.
  
  Indeed you can't.  And nor can you if you were reading printed text
  with some words in bold.  However, you would appreciate that the
  author had wished for some particular words to stand out from the
  surrounding text.  Perhaps you then notice it's being done for all
  brand names?  Or that the emboldened words spell out a secret
  message?
  
  However, you can only notice this if the words have been
  distinguished in some way.  With b, all user-agents can choose to
  convey to users that those words are special.
 
 You cannot make a 100% comparison between printed and web-published
 styling and semantics. Apart from the obvious visual difference, we
 are talking about the ability here to convey semantics other than just
 visual.

Indeed.

 For example to aid machine-readability but far more importantly,
 Assistive Technologies.  If markup in web-publishing was meant to be
 just for visual feedback, we would only need 1 block and one inline
 element as we can do anything with just classes and CSS in that
 respect.

But that would be using a styling technology (and an optional one at
that) for conveying meaning.

Anybody without the CSS -- or with a non-graphical user-agent, which
can't render the CSS rules to the user -- will be missing out.  Such
users wouldn't be able to distinguish span class=legalese or even
span class=secret_message from the surrounding text.

Whereas if small or b are used, all user-agents can do _something_
with them.

So I completely agree with what you say.

Smylers

Re: [whatwg] Deprecating small, b ?

[David Muschiol]

On Fri, Nov 14, 2008 at 06:09, Nils Dagsson Moskopp
[EMAIL PROTECTED] wrote:
The small element represents small print [...]

The b element represents a span of text to be stylistically offset from
 the normal prose without conveying any extra importance [...]

 Both definitions seems rather presentational (contrasting, for example,
 the new semantic definition for the i element) and could also be
 realized by use of span elements.

Why use span class=smallprintCopyright (c) 2008 …/span instead
of just smallCopyright (c) 2008 …/small?  The latter possibility
is way more semantic.

And why use span class=brandSiemens/span instead of just bSiemens/b?

To me, the small and b elements – especially the former – make perfect sense.

-david

Re: [whatwg] Deprecating small, b ?

[Pentasis]

The small element represents small print [...]


The b element represents a span of text to be stylistically offset from

the normal prose without conveying any extra importance [...]

Both definitions seems rather presentational (contrasting, for example,
the new semantic definition for the i element) and could also be
realized by use of span elements.


Why use span class=smallprintCopyright (c) 2008 ?/span instead
of just smallCopyright (c) 2008 ?/small?  The latter possibility
is way more semantic.

And why use span class=brandSiemens/span instead of just 
bSiemens/b?


To me, the small and b elements ? especially the former ? make perfect 
sense.


-david


I agree with the original poster on this.

1) Just because it makes sense to a human (it doesn't to me), does not mean 
it makes sense to a machine.
2) When using small on different text-nodes throughout the document, one 
would expect all these text-nodes to be semantically the same. But they are 
not (unless all of them are copyright notices).
3) small is a styling element, it has zero semantic meaning, so it does 
not belong inside HTML.
4) bSiemens/b also does not tell me anything about the semantics. Is it 
used as a name, a brand a foreign word ? etc. I cannot get that information 
from looking at the b element.


Bert 

Re: [whatwg] Deprecating small, b ?

[Oldřich Vetešník]

Dne Fri, 14 Nov 2008 14:40:20 +0100 Pentasis [EMAIL PROTECTED]  
napsal/-a:



I agree with the original poster on this.

1) Just because it makes sense to a human (it doesn't to me), does not  
mean it makes sense to a machine.
2) When using small on different text-nodes throughout the document,  
one would expect all these text-nodes to be semantically the same. But  
they are not (unless all of them are copyright notices).
3) small is a styling element, it has zero semantic meaning, so it  
does not belong inside HTML.
4) bSiemens/b also does not tell me anything about the semantics. Is  
it used as a name, a brand a foreign word ? etc. I cannot get that  
information from looking at the b element.


Bert


I second that, even though it might have a zero value.

Ollie

Re: [whatwg] Deprecating small, b ?

[Tab Atkins Jr.]

On Fri, Nov 14, 2008 at 7:40 AM, Pentasis [EMAIL PROTECTED] wrote:

 The small element represents small print [...]

  The b element represents a span of text to be stylistically offset from

 the normal prose without conveying any extra importance [...]

 Both definitions seems rather presentational (contrasting, for example,
 the new semantic definition for the i element) and could also be
 realized by use of span elements.


 Why use span class=smallprintCopyright (c) 2008 ?/span instead
 of just smallCopyright (c) 2008 ?/small?  The latter possibility
 is way more semantic.

 And why use span class=brandSiemens/span instead of just
 bSiemens/b?

 To me, the small and b elements ? especially the former ? make perfect
 sense.

 -david


 I agree with the original poster on this.

 1) Just because it makes sense to a human (it doesn't to me), does not mean
 it makes sense to a machine.
 2) When using small on different text-nodes throughout the document, one
 would expect all these text-nodes to be semantically the same. But they are
 not (unless all of them are copyright notices).


Why would you expect this?  Or rather, why would you expect this level of
semantic specificity?  small means something fairly broad that multiple
types of specific semantics can fall under.


 3) small is a styling element, it has zero semantic meaning, so it does
 not belong inside HTML.


It *had* zero semantic meaning.  Actually, though, this wasn't quite true.
The semantics that have been attached to small (and i, and b) are an
approximation of the common semantics that users of the elements conferred
on the contents.  Text within small was, quite often, used for small
print.  Matching up theory with practice is a good thing here.

i and b, once you subtract the semantics stolen by em and strong,
are used pretty much specifically as the spec states.

4) bSiemens/b also does not tell me anything about the semantics. Is it
 used as a name, a brand a foreign word ? etc. I cannot get that information
 from looking at the b element.


Of course not.  You're not intended to.  What you *do* get, though, is that
this is a word which is *intentionally* stylistically offset from the rest
of the text.  This conveys semantic meaning to a human - it means that the
word is special or being used in a particular context.  b and i don't
communicate *much*, but they communicate *something*.  One could, of course,
also use a span to mark up and style the text, thus communicating the same
intent to a person reading the styled text, but to a machine the span
means literally nothing, while b and i have the possibility to
communicate *something*.

In addition, the fact that these elements traditionally have a particular
preferred rendering means something.  A dumb terminal which doesn't
understand CSS won't give any indication to the user that a span exists at
all, while b and i have a chance of providing fallback rendering that
still accomplishes what they were designed to do.  A decent chunk of html5
concerns itself with providing fallbacks and graceful degradation (or
progressive enhancement, whichever way you want to look at it).  Having some
*nearly* semantic-free elements which have a meaningful fallback can be
useful.

Of course, it may certainly be more useful to you if you provide a class on
the i as well.

~TJ

Re: [whatwg] Deprecating small, b ?

[Pentasis]

Of course not.  You're not intended to.  What you *do* get, though, is that 
this is a word which is *intentionally* stylistically offset from the rest 
of the text.  This conveys semantic meaning to a human - it means that the 
word is special or being used in a particular context.  b and i don't 
communicate *much*, but they communicate *something*.  One could, of course, 
also use a span to mark up and style the text, thus communicating the same 
intent to a person reading the styled text, but to a machine the span 
means literally nothing, while b and i have the possibility to 
communicate *something*.


In addition, the fact that these elements traditionally have a particular 
preferred rendering means something.  A dumb terminal which doesn't 
understand CSS won't give any indication to the user that a span exists at 
all, while b and i have a chance of providing fallback rendering that 
still accomplishes what they were designed to do.  A decent chunk of html5 
concerns itself with providing fallbacks and graceful degradation (or 
progressive enhancement, whichever way you want to look at it).  Having some 
*nearly* semantic-free elements which have a meaningful fallback can be 
useful.


Of course, it may certainly be more useful to you if you provide a class on 
the i as well.


~TJ



First: Computers are binary instruments. conveying *something* is not very 
logical seen from a computers point of view. It is not usefull to *me* to 
provide a class to the i or any other element, it is usefull to the 
computer, as humans may indeed come to some sort of conclusion based on 
style or strangely used semantics, computers cannot, they (still) need a 
more literal means of semantics.


Second: Suppose I want to collect all copyright notices from 1000 websites 
(don't ask me why, I just want to), how am I to do this when they are marked 
up in smalls? I will definatly end up with a lot of text that has nothing 
to do with copyrights (and probably miss a lot of copyright notices as they 
are marked up differently) Whereas If they were maked up in (for example) 
span class=copyright I could retrieve it all based on the class-name.


Bert 

Re: [whatwg] Deprecating small, b ?

[Tab Atkins Jr.]

On Fri, Nov 14, 2008 at 9:38 AM, Pentasis [EMAIL PROTECTED] wrote:

 Of course not.  You're not intended to.  What you *do* get, though, is that
 this is a word which is *intentionally* stylistically offset from the rest
 of the text.  This conveys semantic meaning to a human - it means that the
 word is special or being used in a particular context.  b and i don't
 communicate *much*, but they communicate *something*.  One could, of course,
 also use a span to mark up and style the text, thus communicating the same
 intent to a person reading the styled text, but to a machine the span
 means literally nothing, while b and i have the possibility to
 communicate *something*.

 In addition, the fact that these elements traditionally have a particular
 preferred rendering means something.  A dumb terminal which doesn't
 understand CSS won't give any indication to the user that a span exists at
 all, while b and i have a chance of providing fallback rendering that
 still accomplishes what they were designed to do.  A decent chunk of html5
 concerns itself with providing fallbacks and graceful degradation (or
 progressive enhancement, whichever way you want to look at it).  Having some
 *nearly* semantic-free elements which have a meaningful fallback can be
 useful.

 Of course, it may certainly be more useful to you if you provide a class on
 the i as well.

 ~TJ



 First: Computers are binary instruments. conveying *something* is not very
 logical seen from a computers point of view. It is not usefull to *me* to
 provide a class to the i or any other element, it is usefull to the
 computer, as humans may indeed come to some sort of conclusion based on
 style or strangely used semantics, computers cannot, they (still) need a
 more literal means of semantics.


If we wish to communicate that level of semantics, yes.  It may not be
useful to us.  If you *really* need some metadata/semantics, @class probably
can't convey it with enough granularity.  Check out the big discussion from
a few months ago about ccRel and RDFa.


 Second: Suppose I want to collect all copyright notices from 1000 websites
 (don't ask me why, I just want to), how am I to do this when they are marked
 up in smalls? I will definatly end up with a lot of text that has nothing
 to do with copyrights (and probably miss a lot of copyright notices as they
 are marked up differently) Whereas If they were maked up in (for example)
 span class=copyright I could retrieve it all based on the class-name.


That would be a wonderful perfect world.  I'd like the copyright date as
well, so I can retrieve only things copyrighted in the last ten years.
Assuming that metadata will exist is a fool's errand.  The fact is that if
you are searching for copyright notices, the most efficient way is likely to
just search for the string copyright and the (c) symbol.  That'll net you
copyright notices with a high accuracy, and some training on real data can
yield further rules to improve the data-mining accuracy.

While we're hoping for copyright notices to be marked up as span
class=copyright, though, why not wish for small class=copyright?  If
you're going to be providing metadata, it works the same.  Is it that you
believe people won't provide a special class for copyrights if the small
tag already gives them the preferred display?  Do you believe that everyone
will automatically use class=copyright to mark up their copyright
notices?  What if they use class=copyright-notice?  Or class=license?
Or any of a million other distinct possibilities that would destroy any
naive attempt to datamine based on a particular class name?

~TJ

Re: [whatwg] Deprecating small, b ?

[Pentasis]

If we wish to communicate that level of semantics, yes.  It may not be 
useful to us.  If you *really* need some metadata/semantics, @class probably 
can't convey it with enough granularity.  Check out the big discussion from 
a few months ago about ccRel and RDFa.
 

Not yet maybe, but we could at least try to keep options open for the future.


Second: Suppose I want to collect all copyright notices from 1000 websites 
(don't ask me why, I just want to), how am I to do this when they are marked 
up in smalls? I will definatly end up with a lot of text that has nothing 
to do with copyrights (and probably miss a lot of copyright notices as they 
are marked up differently) Whereas If they were maked up in (for example) 
span class=copyright I could retrieve it all based on the class-name.

That would be a wonderful perfect world.  I'd like the copyright date as 
well, so I can retrieve only things copyrighted in the last ten years.  
Assuming that metadata will exist is a fool's errand.  The fact is that if 
you are searching for copyright notices, the most efficient way is likely to 
just search for the string copyright and the (c) symbol.  That'll net you 
copyright notices with a high accuracy, and some training on real data can 
yield further rules to improve the data-mining accuracy.

You say it yourself, only in a perfect world where all websites in the world 
would be written in the same language would your solution work. Unfortunatly 
I would miss out on all the chinese copyright stuff.
But another example (based on siemens) wouldn't it be nice if I could tell 
Google I am looking for a person named Siemens so it would ignore the 
brand-name?


While we're hoping for copyright notices to be marked up as span 
class=copyright, though, why not wish for small class=copyright?  If 
you're going to be providing metadata, it works the same.  Is it that you 
believe people won't provide a special class for copyrights if the small 
tag already gives them the preferred display?  Do you believe that everyone 
will automatically use class=copyright to mark up their copyright notices? 
 What if they use class=copyright-notice?  Or class=license?  Or any of 
a million other distinct possibilities that would destroy any naive attempt 
to datamine based on a particular class name?


Well, that would have to be defined in the standard, wouldn't it? I'm not 
saying -again- it should be defined NOW, but at least leave the door open.
I have no problems with using small over span, neither one is correct as far as 
I can see, in this context. Using copyright instead of license or 
copyright-notice would have to be defined somewhere, either in the standard 
or in an externally maintained document that is accepted as best practice 
or standards related.

PS: I find it very difficult to respond to rich-text/html messages as they 
seriously mess up the indentation. Sorry therfor if this message is unclear as 
original message and reply are mixed up.

Re: [whatwg] Deprecating small, b ?

[Tab Atkins Jr.]

On Fri, Nov 14, 2008 at 10:44 AM, Pentasis [EMAIL PROTECTED] wrote:

  If we wish to communicate that level of semantics, yes.  It may not be
 useful to us.  If you *really* need some metadata/semantics, @class probably
 can't convey it with enough granularity.  Check out the big discussion from
 a few months ago about ccRel and RDFa.


 Not yet maybe, but we could at least try to keep options open for the
 future.


Of course, but I don't think having small in the language closes any
options.


 Second: Suppose I want to collect all copyright notices from 1000
 websites (don't ask me why, I just want to), how am I to do this when they
 are marked up in smalls? I will definatly end up with a lot of text that
 has nothing to do with copyrights (and probably miss a lot of copyright
 notices as they are marked up differently) Whereas If they were maked up in
 (for example) span class=copyright I could retrieve it all based on the
 class-name.

 That would be a wonderful perfect world.  I'd like the copyright date as
 well, so I can retrieve only things copyrighted in the last ten years.
 Assuming that metadata will exist is a fool's errand.  The fact is that if
 you are searching for copyright notices, the most efficient way is likely to
 just search for the string copyright and the (c) symbol.  That'll net you
 copyright notices with a high accuracy, and some training on real data can
 yield further rules to improve the data-mining accuracy.

 You say it yourself, only in a perfect world where all websites in the
 world would be written in the same language would your solution work.
 Unfortunatly I would miss out on all the chinese copyright stuff.


Of course.  But would you expect chinese speakers to use class=copyright
on their pages anyway?


 But another example (based on siemens) wouldn't it be nice if I could
 tell Google I am looking for a person named Siemens so it would ignore the
 brand-name?


Certainly.  But at this point you're expecting authors to mark up their
pages with metadata every time they mention someone's name.  The use of b
doesn't prevent this, but your use-case certainly requires quite a lot more.


 While we're hoping for copyright notices to be marked up as span
 class=copyright, though, why not wish for small class=copyright?  If
 you're going to be providing metadata, it works the same.  Is it that you
 believe people won't provide a special class for copyrights if the small
 tag already gives them the preferred display?  Do you believe that everyone
 will automatically use class=copyright to mark up their copyright
 notices?  What if they use class=copyright-notice?  Or class=license?
 Or any of a million other distinct possibilities that would destroy any
 naive attempt to datamine based on a particular class name?

 Well, that would have to be defined in the standard, wouldn't it? I'm not
 saying -again- it should be defined NOW, but at least leave the door open.
 I have no problems with using small over span, neither one is correct as
 far as I can see, in this context. Using copyright instead of license or
 copyright-notice would have to be defined somewhere, either in the
 standard or in an externally maintained document that is accepted as best
 practice or standards related.


Okay, then we have no issue with small.  There has been some discussion,
btw, about standardizing a set of normative class names.  You should be able
to turn something up about it.

PS: I find it very difficult to respond to rich-text/html messages as they
 seriously mess up the indentation. Sorry therfor if this message is unclear
 as original message and reply are mixed up.


No problem; it was clear enough.  The only richtext I use is quote levels,
and with the conversation context nearby anyway, it's not difficult to
puzzle out when it occasionally messes up.

~TJ

[whatwg] Deprecating small, b ?

[Nils Dagsson Moskopp]

The small element represents small print [...]

The b element represents a span of text to be stylistically offset from
the normal prose without conveying any extra importance [...]

Both definitions seems rather presentational (contrasting, for example,
the new semantic definition for the i element) and could also be
realized by use of span elements.

To me these look like the last remnants of the font element. So why
are these elements retained ?


Greetings,
Nils