Why is XHTML bad?
-
I think this is often a false dilemma. XML is easier to write a parser for and easier to read because there are fewer variations.
I disagree. I believe XML is at best equally difficult to read, and at worst significantly more difficult. XSD can completely change the meaning of an XML tag that might be intuitively "obvious", and that change is hidden from the viewer of the XML unless they also view that completely different document.
At least HTML's all laid-out there in front of you.
-
Who says it is? Who says HTML isn't intended for my grandma to create her knitting club's website on?
I'm really not sure how to respond to this. If Grandma really wants to get into HTML, she should either write well-formed HTML or have someone do it for her. Just like any other engineering discipline.
And for one of my bad analogies: I get that there are all kinds of weekend DIY warriors who build their own sheds but don't bother building a foundation or using insulated and properly-grounded electrical wiring, but the answer is not to dumb down all the national carpentry standards to accommodate them.
Filed Under: ERROR_BRAIN_BSOD
-
What the Discourse happened to my post?
-
Who says it is? Who says HTML isn't intended for my grandma to create her knitting club's website on?
While it's nice to have a human-friendly interface, it's also nice to have a machine-friendly one. Maybe the human-friendly one should have been built on top of a machine-friendly one, just like... computers.
Instead of just having a human-friendly, machine-confusing interface that we then have to get our machines to understand.
Could have saved alot of time of money.
-
I'm really not sure how to respond to this. If Grandma really wants to get into HTML, she should either write well-formed HTML or have someone do it for her. Just like any other engineering discipline.
Something with stakes this low hardly counts as "engineering discipline". It's a fucking website about quilting. Why the fuck shouldn't grandma be able to write it with only minimal effort?
-
I look at HTML and pretty much see XML. I don't see how one is any harder than the other to read...they look like 90% identical.
-
---under textI know.
Let your anger flow through you.
If you want
---to behave like a<hr>you need a newline before it.I know...
-
Something with stakes this low hardly counts as "engineering discipline". It's a fucking website about quilting. Why the fuck shouldn't grandma be able to write it with only minimal effort?
Does this even happen in real life? Once she writes her website does she go buy hosting, deal with DNS, set up an FTP account, and manually publish her HTML?
-
I was just talking about syntaxes. XML doesn't have hanging open-tags which may or may not have a closing-tag, for instance.
If you're going to bring stuff like XSD into it (which I now realize may have been your point the whole time), then fuck everything.
-
Something with stakes this low hardly counts as "engineering discipline". It's a fucking website about quilting. Why the fuck shouldn't grandma be able to write it with only minimal effort?
Grandma should use a WYSIWYG editor anyway, right? I hate them usually, but I still think grandma should use it, because I don't expect her to futz around with HTML. And I'm pretty sure you should agree with me here.
-
When talking about XML, you can't just ignore XSD (XML Schema Definition, after all). XSD is part of XML.
-
Does this even happen in real life? Once she writes her website does she go buy hosting, deal with DNS, set up an FTP account, and manually publish her HTML?
That's not the point.
Now we have to have one of those long tedious discussions about how the people who post here don't understand what the word "should" means.
Grandma should be able to put up the website with minimal effort. That doesn't mean she currently can do it, that means she should be able to do it. Capiche?
-
Why the fuck shouldn't grandma be able to write it with only minimal effort?
She can. Using dreamweaver or whatever.
-
IE, Chrome, Firefox, Opera all pull it off-- what's your excuse?
A shitload of software dealing with XML that could be basically reused for HTML.
Other than that, I kinda agree with Blakey here. Sure, XHTML would be pretty amazing to have as a standard from the get-go, but breaking half the Internet is not a cost you can pay. It's basically what Raymond Chen keeps writing about - there are a lot of ways to do stuff better, but we let people do weird shit in the past and now we have to live with it.
-
She can. Using dreamweaver or whatever.
Right; but again, HTML was invented in like 1992. It's a different world now than the world in which HTML was designed.
-
But the web wasn't mainstream in 1992. So grandmas wouldn't have been making web sites then.
-
Kids these days. This is the problem with computer science, schools teach the current but not the how we got here. Without knowing how we got there, how the fuck can you improve anything? Oh wait you can't, that's one of the main reasons IT sucks ass.
Good luck fixing that. The history of how we got here is all on the internet, accessible via google search. If kids these days don't know it, it's because they aren't interested. That plus:
Every new generation believes it invented everything and is much better at it than the idiots who came before.
-
Okay.
I was thinking of XHTML the way it seems @mott555 does, which is an HTML doc that conforms to XML. So simpler HTML. And I didn't see how that could be harder to understand.
-
Grandma should be able to put up the website with minimal effort. That doesn't mean she currently can do it, that means she should be able to do it. Capiche?
I don't see how better validation on open/close tags is a barrier to that. If anything, an error message saying "
<p>count does not match</p>count" would be just as useful to Grandma as it would be to me, versus the current more-or-less undefined buggy stuff browsers do when pretending there's nothing wrong because some website back in 1996 never used</p>and we need to cater to those few Geocities leftovers that no one visits anyway.
-
That makes sense in theory. All I can say, is it hasn't been my experience working with that kind of syntax. And I've had the problems you describe while using HTML.
Also, html needs to ditch attributes.
-
Okay.
I was thinking of XHTML the way it seems @mott555 does, which is an HTML doc that conforms to XML. So simpler HTML. And I didn't see how that could be harder to understand.
That's all I'm talking about, an HTML doc that conforms to XML. If XHTML has a bunch more than that, then I didn't realize that and sorry for all the confusion.
-
That makes sense in theory. All I can say, is it hasn't been my experience working with that kind of syntax. And I've had the problems you describe while using HTML.
Also, html needs to ditch attributes.
If you think *ML needs to ditch attributes I'd argue you missed the entire point in the first place.
-
That's all I'm talking about, an HTML doc that conforms to XML. If XHTML has a bunch more than that, then I didn't realize that and sorry for all the confusion.
God dammit, mott!
-
Well, not just drop the information they convey, but convey that information in a different way.
When you have a piece of information to add to an element in XML, do it make it an attribute or a child element?
The pros say to make it a child element almost always. For good reason.
Maybe the same applies to HTML.
-
Does this even happen in real life? Once she writes her website does she go buy hosting, deal with DNS, set up an FTP account, and manually publish her HTML?
My mom did it, and she's my kid's grandma, so yes.
-
Also, html needs to ditch attributes.
That doesn't even make any sense. How would you assign an ID to an element? Or a class? Or in-line styling? Or do any of a dozen other things?
Now, if you are talking about specific attributes, HTML5 and CSS3 are working on that by deprecating many style related HTML attributes and forcing people to use CSS.
-
I can only assume he means ad-hoc attributes, because removing attributes makes less than zero sense.
-
My mom did it, and she's my kid's grandma, so yes.
I know I'm probably responding to a troll post, but for everyone else's benefit if your mother is smart enough to deal with DNS and FTP then I buttume she's also smart enough to write more-or-less well-formed HTML.
-
I assume:
<div> <id>boomzillas_div</id> </div>...etc.
-
That makes sense in theory. All I can say, is it hasn't been my experience working with that kind of syntax. And I've had the problems you describe while using HTML.
I think I can help with this question. I used to lurk in the Lisp community. The complaint about parens came up there on a fairly regular basis. People who had been using Lisp for a long time always had the same answer: use an editor that not only matches parens, but also indents automatically based on the parens. That way a mismatch in parens causes the indentation to not be as expected, and the place where it seems to go off kilter will point you to where the fix needs to be made.
-
Bingo, bitch!
-
The pros say to make it a child element almost always. For good reason.
What pros? Everything I've ever read on the subject basically says that it depends. Sometimes it makes complete sense to use child elements, sometimes attributes are the way to go.
Maybe the same applies to HTML.
You're still stuck in the mindset that HTML and XML are closely related. They aren't. In HTML, every "element" is intended to have a structural purpose. Attributes are intended to help modify those structures from their defaults. There is a purpose to the difference between an element and an attribute in HTML, and it works. There's no need to mess with it.
-
Why would an attribute ever be the way to go? (in XML)
-
Why would an attribute ever be the way to go?
This is a good example of the Chesterton's gate thing @boomzilla mentioned. If you don't know when it's a good idea to use attributes, you are in no position to say that they should be removed (your latest edit notwithstanding).
-
Why would an attribute ever be the way to go?
Brevity.
Back when I did tons of XAML, I preferred the shorter
<Button Name="NextButton" Content="Next" Click="NextButton_Click" />over
<Button> <Button.Name>NextButton</Button.Name> <Button.Click>NextButton_Click</Button.Click> <Button.Content>Next</Button.Content> </Button>
-
-
Attributes are intended to help modify those structures from their defaults. There is a purpose to the difference between an element and an attribute in HTML, and it works. There's no need to mess with it.
Except for data-* tags in HTML5 which demonstrate the weakness of this concept.
-
It was a rhetorical question.
The answer this - it is never the way to go.
Also, the Chesterton's gate thing isn't very convincing. It requires me to prove a negative (impossible in this case), instead of others proving positively that attributes are a needed part of the language.
-
Why would an attribute ever be the way to go? (in XML)
Attributes are good for metadata, such as internal IDs. In this situation, you know that the internal ID will never be expanded on, so there is no danger of needing to modify this portion of the schema in the future (other than maybe changing the data type if you switch from integers to GUIDs). Also, if you are transmitting the XML internally and externally, then the data is there when you need it, and is easily unnoticed when it is not needed.
-
Why would an attribute ever be the way to go? (in XML)
Ah you DID miss the point.
Let us take the humble div.
<div id="mydiv">item</div>item is the content, div is dictating what the content 'is', the attribute is information about the div, and should not be mixed with content.
-
Also, the Chesterton's gate thing isn't very convincing. It requires me to prove a negative (impossible in this case), instead of others proving positively that attributes are a needed part of the language.
It's not really about proving a negative, but about finding out why the thing was there in the first place (and in this case, how and why people are currently using it). You may decide it is rightfully obsolete or you may be causing people a shit ton of problems due to your ignorance.
-
instead of others proving positively that attributes are a needed part of the language.
In theory, you don't need a hammer if you have a brick and a crowbar. The brick can be used for driving nails in, and the crowbar for prying them out. Most of us would rather also have a hammer.
-
What if you want more that two different categorizations?
'content', 'attributes'... and now we have 'data'...
-
I think I've done my due diligence.
-
If you have, it didn't work.
-
Yes, what I was proposing was the hammer. Thank you for the analogy.
-
facepalm
-
What if you want more that two different categorizations?
'content', 'attributes'... and now we have 'data'...
Are we going to switch to arguing about NULL and empty strings in databases again now?
-
I'm so misunderstood!
All I want is HTML, but with a different syntax, semantics and use case and variables and functions. Why is everyone so down on this?
-
Are we going to switch to arguing about NULL and empty strings in databases again now?
I think that will be slightly more entertaining and productive than convincing @Bort that he doesn't know what attributes are for.
