Re: name="" deprecated in XHTML

David Dorward schrieb:
> 
> On 1 Jul 2008, at 15:39, Sebastian Mendel wrote:
>> David Dorward schrieb:
>>> On 1 Jul 2008, at 14:20, Sebastian Mendel wrote:
>>>> yes, you can do all the things you could do with name also with 
>>>> class, but you could also do all the things you can do with class 
>>>> with the id
>>> No, you can't. @id does not let you mark an element as being part of 
>>> a group.
>>
>> ... in real world, all you can do with classes in (X)HTML could also 
>> be done with the id, of course in a more complex way ... but this is 
>> not the point
> 
> I suppose you could build an id along the lines of 
> class1-class2-class3-somethingUnique ... but that would make it 
> *extremely* complex to do just about anything with it.
> 
>>>> Depending on which element the attribute is applied to.
>>
>> yes ... in RFC but not in real world
> 
> Trying to give the same name to multiple anchors in the same document 
> will break things.
> 
>>>> it is common to change classes of an element on the fly or dynamic
>>> So what?
>>
>> e.g. changing the style dynamically of an element is done by changing 
>> the class
> 
> I know why it is done, the question was - what does that have to do with 
> your argument?

see below


>>>> name shouldn't
>>> Why not?
>>
>> Why?
> 
> You were the one who made the assertion, please justify it.

in opposite to class, which could be changed to change styling, naming is 
something to rely on what does not change, see above


>>>> classes are overlapping, names not
>>> I have no idea what you mean by that.
>>
>> Elements with name "a" do not interfere with Elements named "b"
>>
>> Elements in class "a" can interfere with Elements in class "b"
> 
> How?
> 
> By default (if we leave microformats aside for the time being), being a 
> member of a class doesn't change an element in any way except to mark it 
> as being a member of that class. This lack of change includes its 
> interactions with and impact on other elements.
> 
> A style applied to an element might change the way other elements are 
> rendered, but the only connection that has to the class is that a class 
> selector might be used (and an attribute selector could be used to 
> change it based on the name).

(in an abstract view ... objects in software are always an abstraction of 
objects in real world, and classes and names are two different things on 
real world objects, and this has a reason, sometimes you need to specify a 
group of objects by its name and sometimes by its class)

this are just my 2 cents, no need to agree, but i am tired of arguing


>>>> it makes things more clear
>>> How so?
>> from real world understanding of the two terms class and name
> 
> My experience seems to be the reverse of yours. I'd say that name was 
> more confusing than class.

naming and classifying objects are two different approaches for me



there is no need to explain my thoughts, if you not agree i have no problem 
with it

-- 
Sebastian Mendel

Received on Tuesday, 1 July 2008 15:56:14 UTC