CSSProperty should be named CssDeclaration about anglesharp HOT 12 CLOSED

AngleSharp is only divided due to historical reasons. In the recent versions AngleSharp shifted from the old API to a interface focused API. The interface all have names like ICssProperty (strictly following .NET convention, while staying close to the original name). This follows the naming convention more closely. The original thinking was closer to the W3C naming, however, since every such object is decorated with an DomNameAttribute attribute anyway, I considered it obsolete.

The interface approach allows easier refactoring (e.g. renaming) of existing (internal) implementations without breaking user code. Renaming will take place at some point (prior to v1.0), but has no priority before (this renaming also includes the whole implementation of the DOM, e.g. HTMLElement, ..., and is therefore work I'd like to postpone - but its on the list).

The naming you propose fits, and I will rename it accordingly (probably already with the new value model being released). However, please note that while I (and I think you as well) speak of declarations (as the CSS3 specification does), many sources (such as MDN) speak of properties.

from anglesharp.

I don't believe this has been fixed - the latest code still has CssProperty.

This is a pretty important name error - you say above that MDN uses the term properties, but if so, that's sloppy and does not match the specification. The combination of property name, colon, and property value within a ruleset is called a declaration everywhere I've seen.

from anglesharp.

I don't think this is an important naming error. Actually it is pretty accurate. A declaration is the combination of a name and a value. The instances of the property classes carry name and value pairs and are called declarations. However, the specific scheme for a certain name is the class, which is called property. I think this is as accurate as you could describe it. If you would name these classes declaration, then you would infer a specific value, however, the value is generic, while the naming is not.

from anglesharp.

However, the specific scheme for a certain name is the class, which is called property.

That is what is confusing. Why is the class called property? The class name should be Declaration, since it has no other purpose.

Sorry if this seems difficult, but this really makes the AngleSharp API and class hierarchy confusing.

As one more piece of evidence, see the specification which says:

To serialize a CSS declaration with property name property, value value and optionally an important flag set, follow these steps:

Therefore property names are called property. The combination of property name and value is called a declaration.

from anglesharp.

That is what I wrote above (please read it carefully - property is the name of a declaration, but it is also the class of declaration). A declaration is the actual instance that connects a value to a property.

[...] the specific scheme for a certain name is the class, which is called property

Naming will always be subject for discussion. But right now I don't see any reason to change. Especially since the naming aligns with other engines.

from anglesharp.

property is the name of a declaration

That could mean two things:
a) Declaration.Name is called property. If that's what you mean, please don't call it the name of a declaration, it is the property name.
b) The declaration itself is called property (that's what the ordinary use of "name" means.)

Language gets confusing in the meta-world :)

Especially since the naming aligns with other engines.

Could you give an example? All the parsers I've seen use the term Declaration consistently...
Here are some examples:
https://github.com/radkovo/jStyleParser/blob/master/src/main/java/cz/vutbr/web/css/Declaration.java
https://github.com/benbjohnson/css/blob/master/ast.go#L54
http://servo.github.io/rust-cssparser/cssparser/trait.DeclarationParser.html
https://github.com/css/gonzales/blob/master/src/cssp.ast.shared.js

Obviously, If you've decided this is not going to change, then I won't say anymore. But I still haven't heard any justification for this naming which leads to code like:

List<CSSProperty> _declarations;

from anglesharp.

There is plenty of justification above. And besides: I don't need justification. But then again: An instance of a property class is a declaration, hence a list of property class instances are declarations. Its just a name: Get over it.

from anglesharp.

And besides: I don't need justification.
Its just a name: Get over it.

Try telling that to these folks.
I can't take offense because statements like this come from the ego.

Let me ask directly - do you want such feedback or not? I'm not interested in wasting my time or getting into pissing matches. Great code is my concern. If you are interested in sincere, sometimes difficult discussions, fine, otherwise I won't bother.

from anglesharp.

Great code yes, but this has nothing to do with the naming guidelines or anything else. Besides, the document you reference is a guideline. If somebody violates the guidelines, this can be intentional and beneficial depending on the scenario.

In don't see a pissing match here. I closed the issue and I justified this. There are users of the library which would be angry by name changes. This is one of the reasons why I want to stay with the current naming. It is not completely inaccurate and I had my reasons.

Just to come back to your statement:

But I still haven't heard any justification

This is not about ego or "being pissed", but why would I need to justify anything here. Any justification is optional. This is important. A discussion is highly welcome, but if I decide in favor of one or the other thing, then I probably have my reasons. Have these reasons been good or bad? That depends on the perspective. Some have been good, some could have been better. Would I have picked the Declaration naming initially, I wouldn't change it to Property now. But I made that decision and it was released prior to the discussion.

A name can be good or bad as well. But a name is really just a label. Nothing more. Therefore I would appreciate discussions about behavior and code and get over a name like that. In that case I evaluated the impact and I considered it not worth the change.

That you are not pleased with that decision is obvious. But I would focus on something else, or the future of the project, instead of moaning about the past.

from anglesharp.

There are a couple of things going on here.

1. It seemed you agreed with me initially:

The naming you propose fits, and I will rename it accordingly

If you hadn't agreed, we wouldn't be having this discussion.

2. In the course of researching #38 I saw the latest code where the name hadn't changed, so came back here and found the issue closed.

I asked about this, and rather than just saying you had changed your mind and decided to do nothing, you provided several reasons, which seemed invalid:

• You said other engines use this term, but no examples were given, so I did some research to see what the actual consensus out there is, and they all seem to use the term Declaration.
• The language you use, I must gently suggest, may make sense to you but tends to be unclear and imprecise. That's why I try to be as detailed and sharp - no generalizations or philosophy.
• The idea that the name of a class is unrelated (and in this case means something totally different) to the names of instances of the class is just... weird.

Only in the last comment did you touch on something approaching justification, namely that you're not changing this for compatibility reasons. Fine. I'm simply restating my opinion that this is a wart, IMHO, in the api. We differ on one thing - to me names in code are extremely important, and make the difference between a clear, pleasurable codebase and an annoying, unpleasant one. This particular name is, to me, one of the more confusing ones I've come across. Otherwise I would not have bothered to bring it up.

You must realize for someone to take such a matter seriously is the kind of thing that should be encouraged. That's the best part of open source. Projects run on dogma tend to get forked and/or sidelined in the long run.

The fact that you initially agreed and then closed the issue without comment and now appear to be irritable is - disconcerting.

BTW - our English usage seems to be different, so I'll keep American slang out in the future. A pissing match is not about "being pissed." Also my link to the naming guidelines was ironic, and because it was not realized makes it doubly ironic :)

from anglesharp.

If we're done with this issue, why not discuss #38 - that's much more interesting :)

from anglesharp.

Sorry that I did not spot your irony. The discussion so far did not indicate that you are being ironic about such things. Hence an emoticon just like the one above would have been enough to provide a hint ;).

Anyway, yes I initially agreed and I am still not totally opposed to that name (I never said that it is wrong or not true, I just wrote that the current name is not completely wrong, even though it is less accurate -- but again: the impact would have not justified the refactoring step).

Since you are still interested in other engines I only want to mention WebKit (but Blink naturally, Gecko and from the internals also IE are similar). You can see an example at the header file of the CSS property http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSProperty.h.

Sorry but the name of the class and the instance are unrelated in general. If I make a class for only a single instance, then something may be fishy. The name of a particular instance might be close or related to the class, but in general there is no such requirement.

Also the "being pissed" was totally unrelated to the "pissing match". See above. It was a reference to the ego statement:

I can't take offense because statements like this come from the ego.

I don't know why you connected them, just because both contain "piss" does not mean that one was a reference to the other.

So let's close this issue for good and focus on the future instead of the past.

from anglesharp.