Although I don’t really want to point fingers here, I appreciate you sharing your experience with the work. And following some of the discussions, I do agree that the understanding about accessibility in the group seems to leave you wishing for more.

If this man wants to mock disabled men, maybe he should not be involved in web standards featuring so much accessibility issues.

For more evidence of his “attitude” http://hsivonen.iki.fi/wannabe/

But then, he’s a man who has lived in academia for a long time, perhaps his social skills are not quite tuned to the real world yet.

Do your team rules require a consistent quote character in XML and e.g. Python?

It naturally depends on the team and on the project, but the goal (not saying that it happens all the time) is to be consistent no matter the language.

We could do disabled=”true” but due to legacy reasons we are unable to do disabled=”false”. Allowing only disabled=”true” as conforming would cause confusion, so it is better to allow neither as conforming.

If that’s the case, I agree. Consistency is the main objective to strive for, in my opinion.

I agree that it maybe doesn’t cause any technical harm; my opinions are from the perspective of working with a number of different web developers with various skill sets, on the same code, and therefore I personally prefer stricter guidelines to enforce more consistency.

Do your team rules require a consistent quote character in XML and e.g. Python?

In general, it makes sense to use single quoting in human-written code, because single quotes are more ergonomic to type on common keyboard layouts (and Dvorak, too). Machine generated code is biased towards double quoting, because the entity asymmetry in IE.

To me, at least, that sounds fine. But I agree with Nicolas that its actual value, the same you would give it when scripting it, would be better. For example:

disabled="true"

We could do disabled="true" but due to legacy reasons we are unable to do disabled="false". Allowing only disabled="true" as conforming would cause confusion, so it is better to allow neither as conforming.

To me, at least, that sounds fine. But I agree with Nicolas that its actual value, the same you would give it when scripting it, would be better. For example:

disabled="true"

I’m not particularly pleased with disabled=”disabled”, this is redundant and waste time to write. Using only disabled is not the correct way, but maybe a status attribute will be better?

In (X)HTML5, disabled="" and disabled="disabled" are both conforming.

In HTML5, the empty attribute syntax (i.e., without =”") means that the value is empty, and so disabled and disabled="" are equivalent.

Does that help remove the redundancy?

Thanks for your comment; seems like we agree on most things then.

Do you think that a span tag will be better? I don’t really think so…

For inline formatting, yes. But if it’s for a blocke element, I think it should be applied as a class to that, and not add any extra elements at all.

I’m 22 and I agree but some people listen, the problem is how to tell.

Oh, definitely. Naturally people should listen, but how to tell things to get them across is about respect and skills, too.

I’m not particularly pleased with disabled=”disabled”, this is redundant and waste time to write. Using only disabled is not the correct way, but maybe a status attribute will be better?

I agree for the “no version number in the doctype”, but doctype is unfortunately something we write, not users. They don’t care about which version of HTML is used…

Font is something we hope to never see again. But for compatibility we need it. And I’m sure that some WYSIWYG editor or scripts still use it…
Do you think that a span tag will be better? I don’t really think so…

> especially with people who are around 20 [...] don’t waste your time trying to tell others how to do their job, because they sure as hell won’t listen to you.
I’m 22 and I agree but some people listen, the problem is how to tell.

If it will be as zcorpan suggests above, I think it can become a reasonable situation.

Oh, I know. But why I expect that it will be ok in HTML 5 is from Simon Pieters’ statement:

Do you need to be consistent with the use of /> vs. >?
No.

I’m not sure that is going to change in HTML 5.

Good seeing you here!
I agree that it maybe doesn’t cause any technical harm; my opinions are from the perspective of working with a number of different web developers with various skill sets, on the same code, and therefore I personally prefer stricter guidelines to enforce more consistency.

In HTML, quote omission and boolean attributes without an equals sign have been proper for years.

Oh, absolutely, proper as in correct, but just less consistent. Less experienced web developers seem to have an easier time grasping XHTML since everything has to be closed, and you aren’t allowed to omit any end tag, as opposed to HTML, which takes more skills and knowledge to know when it’s ok and when it’s not.

In HTML, the slash at the end of void element tags was previously non-conforming. It was too hard for many people and a change to allow the slash in HTML5 was lobbied in against Hixie’s personal opinion.

Given Hixie’s famous document, I can imagine that he didn’t like that decision.

Also, good to hear about font!

Lachlan,

I won’t get too upset about font then, I promise.

Yes, I understand that enforcing a certain convention will certainly upset some people, and maybe the document isn’t the right place. It’s just that my personal experience is that you need to be tough with web developers, or they will just ad lib too much.

It would help if people would remain calm and rational.

Most definitely. I think that the discussion here, for instance, has been great. Commenters with strong opinions and great knowledge has been humble and completely open to listening to other people’s input and tried to understand their perspective.

Thank you!

Regarding code conventions, like attribute quoting, attribute minimisation, void element syntax, etc. that’s really a matter of personal opinion and I can guarantee that if the spec tried to enforce one particular convention to please people like yourself, there will be plenty of other people complaining. Enforcing code conventions would be the job of a lint (e.g. like HTML Tidy), not a true conformance checker. Authors are free to make use of lints that warn about conventions if they like, but we shouldn’t enforce one set of conventions upon everyone through conformance requirements.

The attitude problem seems to be a result of people not accepting their ideas being questioned or constructively criticised and then getting all defensive. It’s unfortunate, but when one side gets all defensive and argumentitive, so does the other side and the problem escalates into attacking each other. I know I’ve been attacked several times just for questioning another’s POV and/or asking for clarification. It would help if people would remain calm and rational.

In general, you can add attributes to an element in any fashion you like.

To put things into perspective, the choice of quoting does not cause any technical harm and XML does not require you to be consistent with your attribute quoting, either.

Quick closing of elements is also optional, meaning that any of the below, mixed together in the same document, are ok

Again, to put things into perspective, the choice of void element syntax does not cause any technical harm and XML does not require you to be consistent with your empty element syntax, either.

Proper code for attributes and closing elements can’t be that hard, can it?

In HTML, quote omission and boolean attributes without an equals sign have been proper for years. In HTML, the slash at the end of void element tags was previously non-conforming. It was too hard for many people and a change to allow the slash in HTML5 was lobbied in against Hixie’s personal opinion.

I sincerely can’t believe that the font element is still allowed.

The current spec language regarding font is a failed experiment. I would not spend too much energy on that part of the spec at this time.

It’s an interesting discussion. Who is the document main target audience?

The main target audience is implementors of software that consumes HTML. I expect tutorials, O’Reilly books, etc. to be published for Web authors.

And yes, every team should have a style guide no matter how strict or not the specification says.

You are welcome to configure your editor to use the indent style of your choice, but I think the definition for document conformance is the wrong place to enshrine your favorite indent style as the only right one.

As a serious web developer, I doubt merely writing code to a some specification will earn you the $100/hr jobs.

Absolutely not, but it’s definitely a good start to know how to write proper code, and all the benefits of having valid code.

zcorpan,

What is considered conforming for authors to use does not affect web browser logic at all.

I can understand that consistent coding style can ease maintenance in a development team, but is document conformance the right place to enforce it?

It’s an interesting discussion. Who is the document main target audience? Is it to make life easier for web developers of web browser vendors? I imagine the answer, naturally, is both, but what if you come to a point where you have to choose?

I can’t really tell if the right place to enforce it is in a document or not. Personally, I think I’d prefer that, but maybe many other wouldn’t.

And yes, every team should have a style guide no matter how strict or not the specification says.

In development environments, the more options you give web developers (meaning options than can be contradictory to each other), the more inconsistent code will be.

And, for maintenance purposes of code and I guess alo web browser logic, I believe it would be better with fewer options to accomplish the same thing.

What is considered conforming for authors to use does not affect web browser logic at all.

I can understand that consitent coding style can ease maintenance in a development team, but is document conformance the right place to enforce it? Isn’t it better to have an internal style guide in the development team? You might need it anyway if you want consistent bracing style for the programming languages you use, which a conformance checker won’t see.

What I target here is solely web professionals building web sites for multinational companies or, even more important, the public sector, where a lot of people depend on being able to access the web sites they build.

First, my apologies for getting your name wrong.

Is WHATWG targeting you, a serious web developer, or are they putting in place a specification that will deal with the chaos that you speak of. From what I’ve read from Ian H., this specification is meant to stand the test of time, to deal with syntax error’s gracefully, etc. etc.

As a serious web developer, I doubt merely writing code to a some specification will earn you the $100/hr jobs. I might imagine that the luster of “I write valid XHTML” might wear off sometime soon. Not that it’s not important, but it’s just part of the pie.

Maybe XHTML 2 is more fit to your desires?